I've created lots more samples using adobe's GIL graphics library available at: www.reportbase.com/gil-tests.tar.gz Samples included text rendering, line drawing, and polygon filling. If you need a sample on something in particular, let me know and I'll try to add it. I've got many more that explore polygon filling but I'm having trouble with drawing speed. If you've got experience with Bezier curves, let me know.
Tom Brinkman wrote:
I've created lots more samples using adobe's GIL graphics library available at:
www.reportbase.com/gil-tests.tar.gz
Samples included text rendering, line drawing, and polygon filling. If you need a sample on something in particular, let me know and I'll try to add it. I've got many more that explore polygon filling but I'm having trouble with drawing speed.
A nice idea is to fork AntiGrain 2.4 into something Boost-like and integrate it with GIL. If I had time to spare, this is what I would do. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
A nice idea is to fork AntiGrain 2.4 into something Boost-like and integrate it with GIL. If I had time to spare, this is what I would do.
Do you really mean integrate, as opposed to, say, layer on top of ? It seems to me GIL serves a rather specific domain, which rendering is not strictly a part of. (I'm slightly worried, as this complicating things by extending the problem domain seems to be rather common syndrome.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Joel de Guzman wrote:
A nice idea is to fork AntiGrain 2.4 into something Boost-like and integrate it with GIL. If I had time to spare, this is what I would do.
Do you really mean integrate, as opposed to, say, layer on top of ? It seems to me GIL serves a rather specific domain, which rendering is not strictly a part of.
Yep "layer on top of" is what I mean. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Stefan Seefeld wrote:
Joel de Guzman wrote:
A nice idea is to fork AntiGrain 2.4 into something Boost-like and integrate it with GIL. If I had time to spare, this is what I would do.
Do you really mean integrate, as opposed to, say, layer on top of ? It seems to me GIL serves a rather specific domain, which rendering is not strictly a part of.
Yep "layer on top of" is what I mean.
- and on top of that a layer of simpler to use (or more conventional) 2D, 3D, APIs. A good start is the existing Agg2D - and on top of that ... I like this idea a lot myselves. But as it stands licencing may be an issue if someone ever makes a boost proposal based on AGG. Even if the existing AntiGrain 2.4 is under a licence that may be fully compatible with boost, it is not the Boost Software Licence. Is this an issue that should be attemted resolved up front? Clearly the best way is to get the copyright holder to re-licence or tripple-licence if you like AGG 2.4. I have no idea whether that is realistic, however he once approached the mailing list to see if there was interest for an early version of AGG. -- Bjørn
Tom Brinkman wrote:
I've created lots more samples using adobe's GIL graphics library available at:
www.reportbase.com/gil-tests.tar.gz
Samples included text rendering, line drawing, and polygon filling. If you need a sample on something in particular, let me know and I'll try to add it. I've got many more that explore polygon filling but I'm having trouble with drawing speed.
Wow, this look like a really cool base to starting making robust additions to GIL. Looking at polygon.hpp there are many things that jump out at me as obvious performance pitfalls but I'll have to look deeper to make sure I'm not missing something clever. Thanks, Michael Marcin
Tom Brinkman wrote:
I've created lots more samples using adobe's GIL graphics library available at:
www.reportbase.com/gil-tests.tar.gz
Samples included text rendering, line drawing, and polygon filling. If you need a sample on something in particular, let me know and I'll try to add it. I've got many more that explore polygon filling but I'm having trouble with drawing speed.
I'm using a library called DirectFB, which is a relatively thin wrapper around 2D hardware graphics acceleration. Operations like rectangular copies and fills are hugely faster than letting the CPU do the work. x86 hardware also has the MMX and SSE SIMD instruction set extensions which can give significant speedups, e.g. processing the 3 8-bit channels of an RGB pixel (or potentially 2 or 4 pixels) in one instruction. So I have been wondering about how a graphics library that's not hardware-specific, like GIL or Anti-Grain or FreeType, can best be combined with hardware-specific features. For example, if I want to draw a rectangle with curved corners, then ideally I'd use the graphics hardware to draw the body of the rectangle and then do the details of the corners from the CPU, using MMX instructions to process whole pixels at a time. What sort of architecture would allow the maximum exploitation of available speedups, with the simplest possible interface? Any thoughts anyone? Phil.
On 10/17/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
I'm using a library called DirectFB, which is a relatively thin wrapper around 2D hardware graphics acceleration. Operations like rectangular copies and fills are hugely faster than letting the CPU do the work.
Isn't this only possible on hardware with Frame Buffer Object support, or does DirectX not have the same limitations as OpenGL? In OpenGL, if the OpenGL context is not visible, the contents of the frame buffer are undefined, so one has to use Frame Buffer Objects or PBuffers to do what you are talking about. Definitely not a show stopper (we do similar things for calculating Line of Sight where I work), but something to keep in mind. This is traveling down the route of needing an accelerated graphics library in Boost...think of all that your request entails. Querying graphics hardware for capabilities, setting up extensions (if OpenGL), FBO construction, rendering to target, etc. Your request requires nearly a full graphics pipeline if you want to do it correctly and extensibly.
x86 hardware also has the MMX and SSE SIMD instruction set extensions which can give significant speedups, e.g. processing the 3 8-bit channels of an RGB pixel (or potentially 2 or 4 pixels) in one instruction.
This seems like a good extension to GIL.
So I have been wondering about how a graphics library that's not hardware-specific, like GIL or Anti-Grain or FreeType, can best be combined with hardware-specific features. For example, if I want to draw a rectangle with curved corners, then ideally I'd use the graphics hardware to draw the body of the rectangle and then do the details of the corners from the CPU, using MMX instructions to process whole pixels at a time. What sort of architecture would allow the maximum exploitation of available speedups, with the simplest possible interface?
At the top level the interface wouldn't change too much, but the amount of code inside the library would be pretty large (for reasons given above). The last thing to mention is that creating and destroying the rendering context will probably be one of the huge bottlenecks. For instance, if you had 100 rectangles that you wanted to do this to, you wouldn't want the underlying call to create_curved_corners to create an OpenGL context every time, then destroy it on function exit. I'm not sure how to get around that without exposing implementation details to the user. --Michael Fawcett
Michael Fawcett wrote:
On 10/17/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
I'm using a library called DirectFB, which is a relatively thin wrapper around 2D hardware graphics acceleration. Operations like rectangular copies and fills are hugely faster than letting the CPU do the work.
This is traveling down the route of needing an accelerated graphics library in Boost
No, I'm definitely not advocating that. I'm just pointing out that although GIL can integrate well with libraries like Anti-Grain and FreeType, it's less clear (to me) how it can integrate with something like DirectFB's hardware acceleration or CPU SIMD instructions. I would find this sort of integration very useful, and I'm curious to know if others have considered it: for example, I would be surprised if Adobe's products don't use MMX and hardware rectangle-copying. Regards, Phil.
On 10/18/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
No, I'm definitely not advocating that. I'm just pointing out that although GIL can integrate well with libraries like Anti-Grain and FreeType, it's less clear (to me) how it can integrate with something like DirectFB's hardware acceleration or CPU SIMD instructions. I would find this sort of integration very useful, and I'm curious to know if others have considered it: for example, I would be surprised if Adobe's products don't use MMX and hardware rectangle-copying.
Their latest version of PhotoShop was speculated to have optional use of the GPU for some of the effects and filters. Not sure if that was ever confirmed or not. As a side note, both AMD/ATI and NVIDIA have GPGPU SDKs now, so maybe if they are stable enough you could use one of those to optionally use the GPU. FreeType works great with OpenGL. There's a pretty simple library that encapsulates the boilerplate stuff called FTGL. It's definitely not modern C++, but it's extremely simple and actually works in practice. --Michael Fawcett
Hello, 2007/10/17, Phil Endecott <spam_from_boost_dev@chezphil.org>:
So I have been wondering about how a graphics library that's not hardware-specific, like GIL or Anti-Grain or FreeType, can best be combined with hardware-specific features. For example, if I want to draw a rectangle with curved corners, then ideally I'd use the graphics hardware to draw the body of the rectangle and then do the details of the corners from the CPU, using MMX instructions to process whole pixels at a time. What sort of architecture would allow the maximum exploitation of available speedups, with the simplest possible interface?
You might also want to exploit opengl or openvg if available, and of course it should be easy to be port to a different platform, e.g. some embedded system with 2d acceleration. This is very hard if you try acchieve it in a direct/immediate graphics library. There are better chances for the different implementations to make use of possible optimization if it is a non-immediate canvas library. Because then the library can attach persistent information to the drawn objects, and cache calculation results, track changes ... The evas library of the englightenment project does that. But it is a C lnterface and never seems be finished. regards Andreas Pokorny
participants (8)
-
Andreas Pokorny -
Bjørn Roald -
Joel de Guzman -
Michael Fawcett -
Michael Marcin -
Phil Endecott -
Stefan Seefeld -
Tom Brinkman