Announcement

Collapse
No announcement yet.

Cairo Proposed To Become Part Of ISO C++

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Marc Driftmeyer View Post
    All the more reason Cairo devs should shoot it down.
    Even if they could (which the license they use doesn't allow), why would they shoot it down?

    Comment


    • #52
      Originally posted by Ancurio View Post
      Are you implying that because of the other added features, "window creation and event management" have suffered in quality under SDL? Because right now there is not a single cross platform library available that can even claim feature parity with SDL2. If you don't like the fact that SDL2 has a render abstraction, you can just compile it out.
      I'm saying a project with limited resources should focus on a limited scope rather than trying to replace any other third party library. A team or company should not forget who their target is, and stay focused on creating a solid product for a certain market/demand. Doing display and event management across all the target platforms is a massive task by itself.

      Comment


      • #53
        If there's a threading API in the standard library (and there is), there's no reason not to have a drawing API too. Or a networking one (which is already in Boost and the plan I believe is to move it into the standard library at some point.) It's not like they're adding this into the language; they're adding it into the standard library.

        Comment


        • #54
          Talking about standard library, I believe most compiler manufacturers should put a bit of work on modularizing their implementations. I wrote a small patcher in C++, and while the Linux version takes a few KBs (less than 40, IIRC), the Windows version needs to either ship with a ~500-600KB dll or take ~600KB if linked statically, while I only used vectors from the standard library (and a limited subset of its functionality, as the program is really simple).

          Comment


          • #55
            Originally posted by liam View Post
            Surprisingly to me at least is that openvg has very little to no hardware adoption. The implementations that exist are apparently software.I read about this on the fxos mailing lists FYI.
            IOW, it's dead Jim.
            are you sure?
            http://infocenter.arm.com/help/topic....set.graphics/
            http://www.imgtec.com/news/Release/index.asp?NewsID=441
            http://www.freescale.com/webapp/sps/...p?code=i.MX356
            https://developer.qualcomm.com/disco...ems/adreno-gpu
            http://www.nvidia.com/object/tegra-superchip.html
            http://www.vivantecorp.com/en/techno...-graphics.html

            i read openvg support on all those sites..
            yes they're mostly embedded solutions, and yes OpenVG is mostly an api used in embedded (mobile), for now at least
            but that is due to the need for a portable, hw - and os-independent accelerated 2d api being *mostly* felt there (since as far as the pc is concerned Windows already has Direct2D and Mac OSX has CoreGraphics, while linux apparently is fine with unaccelerated Cairo...) and doesnt deny it being one such api

            Comment


            • #56
              Originally posted by RealNC View Post
              If there's a threading API in the standard library (and there is), there's no reason not to have a drawing API too. Or a networking one (which is already in Boost and the plan I believe is to move it into the standard library at some point.) It's not like they're adding this into the language; they're adding it into the standard library.
              The difference is, there's only one way to do threads on any given platform. The threading APIs for Windows, Posix, etc have been stable for decades. They are the perfect target for standardization.

              Drawing, even 2d drawing, is not so simple. Algorithms in this field are constantly evolving. We've moved from software rendering to increasingly programmable hardware (vertex/fragment shaders -> geometry shaders -> hull/domain shaders -> compute), we've moved from 8bit palettes to 16/32bit colors then 64/128bit floating-point formats (for complex effects, HDR), we've moved from bitmap text to path rendering, we've added antialiasing, subpixel antialiasing, kerning, hinting, ligatures.

              Cairo is a good library, but it is already dated. In ten years, any standard based on that will look like the X11 rendering routines look today: pretty much useless.

              It just looks like a huge amount of effort for something people are not going to use in the end...

              Comment


              • #57
                Whoever decided Cairo was a good idea is a complete idiot, Cairo is slow and its Path Implementation is a broken mess. WTF is wrong with these people?

                1. Nvidia Path Rendering (Is the Best in the Industry)
                2. OpenVG (Not as fast as NVPath but its Path Rendering Implementation is just as good)
                3. Anti-Grain Geometry (Software Based, No Hardware Acceleration but its Path Rendering Implementation is just as good)

                Comment


                • #58
                  Originally posted by LightBit View Post
                  You see, if POSIX would be included into ISO
                  why not win32 instead of posix ? see, how useless your suggestion is

                  Comment


                  • #59
                    Originally posted by BlackStar View Post
                    Cairo is a good library, but it is already dated. In ten years, any standard based on that will look like the X11 rendering routines look today: pretty much useless.

                    It just looks like a huge amount of effort for something people are not going to use in the end...
                    even if you are right, in ten years api can be extended/improved
                    while you instead proposing to do nothing at all and use iostreams for ui - clearly better, isn't it ?

                    Comment


                    • #60
                      Originally posted by zester View Post
                      Whoever decided Cairo was a good idea is a complete idiot, Cairo is slow and its Path Implementation is a broken mess. WTF is wrong with these people?
                      whoever doesn't understand that standard describes only interface and not implementation, is a complete idiot

                      Comment

                      Working...
                      X