Re: [gtk-list] Color allocation

[raster redhat com]

On  1 Mar, Square Avenue shouted:
->  
->  Thanks to the people who replied to my last message.  I downloaded gtk--,
->  looked at it, installed it, and am quite happy.  Except....
->  
->  (There's always an "except" :)
->  
->  The fractal engine works, sorta.  I figured out the gtk_idle_add and
->  _remove functions, and even downloaded Jon Trowbridge's Gtk_Canvas widget
->  and used that as the base class for the FractalCanvas class.  Rewrote my
->  previous code to fit into C++, compiled, ran, and waited, and waited and
->  waited... :)
->  
->  Wondering why the mandelbrot set was taking aver half an hour to render
->  (should take a few minutes at the very most) I ran top, and behold! X was
->  taking up 95% of my CPU time.  Hmm...
->  
->  After some investigation, I found the offending function call.  I have an
->  idle function, whose sole purpose in life is to calculate one pixel,
->  display it, and move on to the next pixel, ready for the idle function to
->  be called again.  It looks something like this:
->  
->  void FractalCanvas::idle_function () {
->  
->    // fs is the FractalState class //
->  
->    if (fs->running ()) {
->  
->      // Calculate the pixel //
->  
->      fs->iterate ();
->  
->      // Paint our window //
->      // (one line at a time) //
->  
->      guint x = fs->x_pixel ();
->      guint y = fs->y_pixel ();
->      guint w = fs->width ();
->  
->      set_foreground (*(fs->color ()));    <== Bad line o' code
->      draw_point (x, y);
->      if (x == w - 1)
->        refresh (0, y, w, 1);
->  
->      // Increment to the next pixel //
->  
->      fs->increment ();
->  
->    }
->    else
->      terminate_idle_function ();
->  
->  }
->  
->  If I comment out the marked line of code X's share of the CPU drops down
->  to a reasonable 6%.  But nobody likes looking at a one-color fractal (in
->  this case white), even if it does take 30 seconds or less to render.  :)
->  
->  I assume that in order to solve this particular problem, I need to set up
->  a table of colors ahead of time.  I can implement that into the existing
->  code fine, but I have no idea where to start.  :)  I looked at the
->  tutorial, code, and even the gtk-list archives.  If anybody has any
->  pointers, it would help me a lot, as I've been stuck on this problem all
->  day.  Thanks!

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. 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. 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 - 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.

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.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/