[Gambas-devel] gb3: Image.Draw method is missing when using gb.sdl

[Kevin Fishburne]

On 01/07/2011 05:27 PM, Benoît Minisini wrote:
>> Le mercredi 5 janvier 2011 15:34:53, Kevin Fishburne a écrit :
>>> I'm in the process of converting my app from gb.image only to gb.image +
>>> gb.sdl to improve rendering performance. To my horror I noticed that the Draw method is no longer available. I'm using the following components:
>> Draw.Image is no more available in gambas3, instead you must use
>> Draw.Begin() / Draw.End() on Image objects.
>>
Draw.Image(...) still works but seems to be limited to gb.sdl, as the 
included SDL example app Beastscroll works. Someimage.Draw(...) is 
what's missing from gb.sdl.
>>> gb
>>> gb.image
>>> gb.image.effect
>>> gb.image.io
>>> gb.net
>>> gb.sdl
>>> gb.sdl.sound
>>>
>>> There is a Copy method, though it doesn't have parameters to specify the
>>> destination coordinates or width/height for scaling. It's like the Draw
>>> method with only the first four parameters. Interestingly good old
>>> DrawAlpha seems to still be there (yay!).
>> Draw.Copy() method is only to copy the image or only a part of it, no some
>> sort of Image.Draw() replacement/workaround, see
>> http://gambasdoc.org/help/comp/gb.image/image/copy?v3
>>
Understood.
>>> Should there be a Draw method, or is there a different way to achieve
>>> the same functionality? It looks like using "Draw.Image(...)" will work,
>>> so I may have to integrate my rendering directly into the SDL backbuffer
>>> (Screen_Draw[]), though that would require a rewrite of the rendering
>>> pipeline. Final question, if there was an Image.Draw method, would that
>>> bypass SDL and use software rendering? If so it may be best for me to
>>> rewrite the rendering pipeline so it's pure SDL.
>> In a normal world, Draw.Begin() with an Image object, should work, but in a
>> world with myself as the maintainer/developper of the sdl component, it's
>> not! Why ? Because i'm really a lazy guy. It should be done from a long
>> time, but as everybody, i'm a bit busy, with projects/familly/job/...
>>
>> Drawing on Images is planned to be implemented through openGL, so (i hope!)
>> it should be possible to use the power of the graphic card to to some
>> rotation/stretching/zoom dynamicly, and perhaps some other things.
>>
>> Sorry for the lack of features of the sdl component, sincerely.
No problem, I take what I can get because my C/C++ skills are somewhere 
near absolute zero. ;)
> The Image class is implemented both in gb.image and in the graphical component
> (gb.qt4, gb.gtk or gb.sdl).
>
> The methods of the Image class implemented in gb.image work with an image
> whose data is located in the memory of the running process.
>
> With SDL, there is a trick (Laurent will tell if I'm saying rubbish), because
> the image data may be located somewhere else (inside the graphics card). And
> so alterning between gb.image methods (for example DrawAlpha) and methods
> implemented in gb.sdl may force a synchronisation between image data in memory
> and image data on the graphics card, which is usually not a good thing.
>
That's what I was wondering about. One of the images I'm working with is 
about 432 MB (12288 x 12288 @ 24 bpp). DrawAlpha is used on it 
extensively, and the final blit-to-screen is taken from it.

> Kevin, I think that you should try to work directly with OpenGL. :-)
>
> Because, as Laurent said, he will not have the time to implement an Image
> class and the draw methods based on OpenGL, and I won't have the time to
> create a component that will add all the methods you need in the gb.image
> Image class directly.
I was thinking about moving to OpenGL but was a bit intimidated by the 
initial reading of both documentation and tutorials. Guess I'll have to 
start experimenting to see what I can come up with. Thanks for the 
clarification, and hopefully sometime this new year gb.sdl will get some 
love. ;)

-- 
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sales at ...590...
phone: (770) 853-6271