Re: [gtk-list] Re: Color allocation



On Sun, 1 Mar 1998 raster@redhat.com wrote:

> well 1. using a function to draw a single pixel -hwne u have an entire
> array to fill (1000's of them) is bad. the thing to do is just have a
> pointre to the pixle array and set it directly.. the overhead of dumping
> registers to stack then returning from it for a funciton call that in
> effetc just does a single memory write (or 3 byte writes if in RGB - but
> this is concatinated into a single write on the bus level). So first I
> suggest optimising by doing this. 

All of the functions I use (that are defined in FractalState) in the loop
are defined inline, so this should not be too much of a problem.

A 2-D array of guint's might not be a bad idea, though.  I figured
those gdk calls were slowing things down badly, and needed an alternative.
As it is, the actual display updates itself once every line (most
optimised way of doing without taking too long to update the output).

Or since I'm only updating one line per screen update maybe I only need a
1-D array of guint's.  :)

> 2. I suggets NOt using ANY gdk/gtk
> calls within this loop - if oyu read the gdk/gtk code you will see it
> does spend a lot of instuctions just doing sanity checks and adding an
> abstraction which is on top of Xlib which then finally uses tcp/ip or
> unix sockets to communicate with X. 

Sounds good to me... Since the screen does need to be updated periodically
(so the user of the program can tell whether or not the fractal is
actually rendering) I'll concentrate all gdk/gtk calls to once per line.

> First work either in RGB (24-bit)
> and write these RGb values directly, or calulcate a "value" (lets say
> 0-255) then use a lookup table to an RGB value (pre-gerenated lookup
> table - like a palette). Then write the value in thsi table to the pixel
> RGB - 

The lookup table idea sounds best.  One thing, however:  I'm not 100% sure
how to create a palette.

In my previous message, the set_foreground (GdkColor c) function was
causing X to suck up all my CPU time, while my program only got 3%
(ouch).  Taking a look at the code, I saw that that particular function
allocated a color on the color map, then set it as the foreground color of
the Canvas widget.  I did a little deduction as realized that for every
pixel being drawn, X-Windows was being asked to allocate a new color
(hence why it was taking all my CPU time).

So am I correct in guessing that I just have to allocate all these colors
ahead of time, put them in an array, and use that as the lookup table?

The function that Gtk_Canvas::set_foreground () calls is:

gdk_color_alloc(gdk_colormap_get_system(), &c);

> secondly I suggest having your routine do multiple pixels per idle
> loop - basically try and do more than one. gtk will do a LOt of work
> when chekcing the event loop - instruction wise if you look deep into
> the code. Avoid doing any widet code wherever possible - have your code
> do as many pixels that it can do inside that routine whilst still
> allowing it to retain some interactiveness. Also perhaps only updating
> the RGB data to display every line or so (perhaps every 2 or 4 lines).
> Also the system you use to get the data to the display can make a big
> impact. Many methods are optimised for gettign a whole image that is
> already fully rendered to the display in one big block - not updating
> every time a pixel updates.

That is a design goal... :)  This project is currently 5 days old, and I
have approximately 5 pages of code.  When I've gotten a widget that will
dump a fractal nice and quick on the screen I'll throw it on my homepage
for public consumption (this may take a couple of weeks however).

> I hope I have given some hints. Some may not apply to you - others may
> sound stupid now but you might be amazed at what you can gain.

Been very helpful.  Thanks

                                      - Dave

p.s. - Picked a helluva day to quit smoking.  :)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Name:  David Finton                  | "All free software is in Beta.  If
 Email:  dfinton@d.umn.edu             |  there is a free software package
   Web:  http://www.d.umn.edu/~dfinton |  bearing the version number 1.0 or
                                       |  greater, it is obsolete and must
                                       |  be replaced immediately by a
                                       |  newer, better Beta version."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]