[Gtk-sharp-list] Drawing pixbufs to screen FAST..

[Eto]

On January 18, 2005 02:50 pm, Federico Mena Quintero wrote:
> Some things to keep in mind:
>
> - Do your pixbufs have an alpha channel?  Due to the current
> implementation in the X server of the RENDER extension, they may not go
> through accelerated paths.

Actually yes, even though I don't use it.  This is because I'm generating the 
pixbuf on the fly, and generating a 32 bit image is MUCH easier (and faster) 
than 24.  In system.drawing, I have the option of a 32-bit bitmap without 
using alpha..  anything like this for gtk?

I tried 24 bit before, but it didn't make much difference at the time.

> - If you'll be drawings many little pixbufs, it may be faster to
> composite them onto a larger pixbuf without an alpha channel, and send
> that to your window with DrawPixbuf().  Download the gtk-sharp sources
> and see gtk-sharp/sample/GtkDemo/DemoPixbuf.cs, which makes a nice
> animation.

I think sending the entire thing to screen would be a lot slower.. or are you 
thinking to just send portions of the larger pixbuf to screen? 

> - You may want to turn off double-buffering for your widget and handle
> exposures yourself.  EOG has a good example of a non-double-buffered
> image widget that is quite fast.

Hm, lemmie check..  yup.. It's already turned off for the DrawingArea widget. 

> - Can you pre-generate server-side pixmaps out of your pixbufs and keep
> them around?  That way they are likely to live in video memory, and
> blitting will be very fast.

Unfortunately, no.. unless there's an easy and fast way to change the colour 
of pixels in a pixbuf before drawing them.  I could do it this way if I used 
8-bit indexed images.. but then it won't be in video memory anyway so there's 
no point.. hehe  

> If you have a web page or something that shows what you are trying to do
> in your program, we may be able to come up with more concrete
> suggestions.

Hm, good idea! (:  This is for an image viewing/editing application, which 
views (and edits) obsolete (to the world) formats, such as ANSI, Avatar, 
Ascii, RIP.. as well as new formats such as bmp/jpeg/etc.  It's for a very 
niche market, but I've been part of it for many, MANY years.  (:

I've got windows-specific apps for viewing (.net) and editing (win32).  I want 
to make one that does both, but with support for GTK. 

The windows only versions are here:
http://pablo.etoxn.ca

You can download the current GTK (and SWF) version that I'm working on here:
http://pablo.etoxn.ca/PabloDraw-3.0.3.zip

If you run it in windows, pass 'gtk' as the command line to run the gtk 
version ('swf' for windows forms).  It uses a custom GUI toolkit that runs on 
GTK or SWF depending on the platform.

There are a few files included in the above ZIP file to test it out.  The main 
ones i'm interested in making faster are the .ANS files.  For the .RIP files 
i'm drawing directly to the screen, but if drawing the images to screen goes 
fast enough, then I can switch it over (as to provide proper dos aspect while 
animating).   Make sure to set the zoom to 100% when viewing rips, as there's 
a bug in the gtk version with that..

Thanks for your VERY valuable input!

Curtis.