AGG2D-compatibility?
178 views
Skip to first unread message
another gol
Dec 14, 2012, 6:53:55 AM12/14/12
to fog...@googlegroups.com
Hello,
Right now I have a working GUI system under Delphi, that I recently enhanced with AGG2D.
Why AGG2D? Well, not just because it's much easier to use, but also because it was possible to import a C++ DLL of it to Delphi. Both AGG & AGG2D were actually fully ported to Delphi, but because Delphi's compiler is rather poor, it's much slower & thus wasn't an option.
On the other hand, I didn't need that much more than what AGG2D has to offer. I'm not using its font & bitmap capabilities, as I use other stuff for this (custom stuff & Intel's IPP for bitmaps, and a spinoff of AGG's more recent rasterizer for fonts).
So I'm pretty much using fills/stroking, & we hacked gradients a little so I'm building gradients locally. The stuff I'm building (scalable audio-related controls) depends mainly on linear/radial (I use custom stuff for conic gradients but we plan to import that to AGG2D as well) gradients. Shadows would be nice, but require CPU-expensive blurring, even IPP's blurring functions aren't that fast. I'm not missing too much using AGG2D, except dithering in gradients maybe.
We also use standard 4x8bit ARGB - as much as I'd love 16bit, our stuff will still have to be GDI-compatible for quite some time, & I have a ton of asm-powered functions made for this format anyway.
So I was thinking, not knowing much about FOG yet (I can't even read C++), would it be already technically possible to build an AGG2D-compatible (or nearly) engine out of FOG?
AGG2D seems already abstracted enough, so..
I've already built quite some code that rasterizes GUI controls, purely by code. You might think it's a mistake & this should have used SVG, but not really, as those controls are very dynamic & parametric, and also rely heaving on good snapping to pixels, there is no way all this could have been assisted by SVG. Problem is, it's a lot of code to adapt if the API changes..
Right now I have a working GUI system under Delphi, that I recently enhanced with AGG2D.
Why AGG2D? Well, not just because it's much easier to use, but also because it was possible to import a C++ DLL of it to Delphi. Both AGG & AGG2D were actually fully ported to Delphi, but because Delphi's compiler is rather poor, it's much slower & thus wasn't an option.
On the other hand, I didn't need that much more than what AGG2D has to offer. I'm not using its font & bitmap capabilities, as I use other stuff for this (custom stuff & Intel's IPP for bitmaps, and a spinoff of AGG's more recent rasterizer for fonts).
So I'm pretty much using fills/stroking, & we hacked gradients a little so I'm building gradients locally. The stuff I'm building (scalable audio-related controls) depends mainly on linear/radial (I use custom stuff for conic gradients but we plan to import that to AGG2D as well) gradients. Shadows would be nice, but require CPU-expensive blurring, even IPP's blurring functions aren't that fast. I'm not missing too much using AGG2D, except dithering in gradients maybe.
We also use standard 4x8bit ARGB - as much as I'd love 16bit, our stuff will still have to be GDI-compatible for quite some time, & I have a ton of asm-powered functions made for this format anyway.
So I was thinking, not knowing much about FOG yet (I can't even read C++), would it be already technically possible to build an AGG2D-compatible (or nearly) engine out of FOG?
AGG2D seems already abstracted enough, so..
I've already built quite some code that rasterizes GUI controls, purely by code. You might think it's a mistake & this should have used SVG, but not really, as those controls are very dynamic & parametric, and also rely heaving on good snapping to pixels, there is no way all this could have been assisted by SVG. Problem is, it's a lot of code to adapt if the API changes..
Reply all
Reply to author
Forward
0 new messages