[Gambas-devel] signal 6 upon use of Blur method

[Kevin Fishburne]

On 02/22/2011 08:04 PM, Benoît Minisini wrote:
>>> It seems that the Blur and Sharpen methods of the imlib library free the
>>> image data, whereas they should not, as the original image data is owned
>>> by the gb.image component.
>>>
>>> Here is the solution: Blur and Sharpen will create a new image, and won't
>>> try to work on the current data!
>> You can look for that fix in revision #3605.

Awesome, thank you. I'm compiling now and will give it a test.


> I added a Image.Scroll() method in the imlib component (revision #3606). Maybe
> you will have a use of it.

Wow, you're really on a roll! :) I'll test that out as well. If it's 
more efficient than "copy A to B, copy B to A" then I'll be extremely 
happy to implement it. Anything to speed up the frame rate is great.


> Another point: I can reimplement some methods of gb.image (like
> Image.DrawAlpha) in the gb.image.imlib component, to use the imlib methods
> that will be faster than mine (as they are independent of the image format and
> so not optimized).

Anything that would help consolidate the different image formats used by 
different components is a huge plus. I use both Draw and DrawAlpha 
extensively in my app, so it should make a big difference if less format 
conversions are occurring.

On a related note, I'm getting pretty good rendering times doing things 
like image1.Draw(image2, ...). What seems to be a LOT slower is using 
the Draw.Begin(DrawingArea) block. For example, the following code was 
looped for 30 seconds using a DrawingArea and images of 1280x720 (imlib 
& gtk):

Draw.Begin(DrawingArea)
   Draw.Image(image1, 0, 0)
   Draw.Image(image2, 0, 0)
Draw.End

58 frames per second.

Draw.Begin(DrawingArea)
   image0.Draw(image1, 0, 0)
   image0.Draw(image2, 0, 0)
Draw.End

104 frames per second.

image0.Draw(image1, 0, 0)
image0.Draw(image2, 0, 0

106 frames per second.

The Draw.Begin/End block has very little overhead (104 versus 106 fps), 
but writing to the DrawingArea seems to be much slower than writing 
image to image. I'm guessing this is because GTK/Qt use a different 
image format, thus requiring a conversion, or than there's something 
going on with the DrawingArea control or window manager.

Again, thanks for your work on this. Here's a screenshot of my progress 
so far and a good illustration of how DrawAlpha is being used:

http://www.eightvirtues.com/sanctimonia/images/Sanctimonia_Alpha_Tiles_2.png

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