Considering moving from PocketFrog...

[fzammetti]

[efortier]

To answer your questions:

> Drawing circles

Nope.


> Cloning a surface

No, but creating a new surface and blitting an image to it is trivial. A cloning function could be made by you in seconds.


> Pixel shaders

No, but GapiDraw provides direct access to the memory of each surface. This way you can implement special effects. GapiDraw in its current implementation does not contain 3D rendering btw.

Something very important you would get by moving to GapiDraw is the great support. Johan (the creator) has been extremely supportive of GapiDraw and it can now run on a wide range of devices. It's also optimized a lot!

--Eric

[fzammetti]

> Drawing circles

> Nope.

Johan, I would like to suggest adding this. I think I Recall you have primitive drawing tools for lines and rectangles, I think circles (or better still, ovals, which would of course include circles as a subset) would be a worthy inclusion. In addition, a poly drawing function would round out the primitive drawing tools nicely (also make all the closed form tools able to fill at the same time).


> Cloning a surface

> No, but creating a new surface and blitting an
> image to it is trivial. A cloning function could
> be made by you in seconds.

Granted it is easy to do, but this is another suggestion for Johan... I would have to believe that creating a surface and blitting an existing image to it would not be an optimized solution like a built-in clone method would be. This is something that would really help sell me on GD (note that I agree with most people that GD is the better library at this point, but I'm just pointing out the areas that I think PF has advantages that GD can learn from).


> Pixel shaders

> No, but GapiDraw provides direct access to the
> memory of each surface. This way you can implement > special effects. GapiDraw in its current
> implementation does not contain 3D rendering btw.

PF also gives you this ability, however, performance-wise, pixel shaders are far better. I would expect that to be true with GD as well, so I would like to suggest adding that too. This is actually the least important thing to me, the surface cloning however is something I have used fairly extensively and would like to see native in any library I decided to use. A full set of primitive drawing tools comes next.

[Hosed]

Good primitive drawing is a non-trivial feature set. There are literally hundreds of algorithms for drawing primitives fast, or pretty, or both. I don't imagine this coming to GapiDraw right away, but Johan would be the one to know.

Cloning is the same thing as creating a surface and doing a memcpy IE Create Surface, Blit Surface. The only possible performance boosts could come from refcounted cloning. In which case you still suffer the costs of cloning, just that they wouldn't incur until you changed one of the clones. Until then they'd all point to the original surface. This latter effect can be achieved just as easily with pointers to CGapiSurfaces.

Needless to say the late copy method is not something you want in a realtime app like a game.

Pixel Shaders are an interesting architecture idea. Completely foreign to most 2D library models I've used, but very neat. However I fail to see how a pixel shader would be any faster then direct access pixel manipulation. Performance wise that is.

[fzammetti]

[efortier]

[fzammetti]

[warmi]

[fzammetti]

[warmi]

[fzammetti]

[Sm!rk]

[fzammetti]

[Sm!rk]

[Johan]

Away from the email for two days and whoooo.. Lots of new posts..

fzammetti: The GapiDraw BltFast operation is actually quite cool. It will try the following operations depending on how surfaces are stored:

(1) memcpy (both surfaces have same pitch and size)
(2) memcpy each row (both surfaces have same yPitch and are wide)
(3) unrolled copy of each row
(4) aligned 32-bit copy source to destination
(5) source-aligned 32-bit read source to destination
(6) unaligned 16-bit pixel-by-pixel copy

Personally I don't like the DrawCircle function, mostly since it's impossible to get it accelerated by operating on multiple pixels (in contrast to DrawRect, DrawLine, etc). That's why it's not in GapiDraw, and most probably never will be. I'll put a feature in GapiDraw if it can be accelerated by analyzing the display orientation of the device. DrawCircle can't. But it's a trivial implementation.

Pixel shaders are also not there, but as many has said, using Get/Release buffer solves that as well...

Keep those questions coming!