Re: Still not understanding pixmaps vs RGBs

["Lewin A.R.W. Edwards" <larwe larwe com>]

Hi Taura (And thanks for all the help so far).

> > * Decimate or expand content, using my own hand-rolled code, into a 
> > second RGB buffer that is screen-sized.
> > * Draw the RGB buffer into a darea that covers the whole screen (this 
> > step is slow).
>
> I don't think you would need RGB buffers *AND* GdkPixmaps togeather.
> You can do all the drawing on client side to yer RGB buffer then send
> it to the X server to a GdkWindow and yer all done.


OK, but then we're back to the old problem. Given that I KNOW my sever 
doesn't support DGA or Xv, how is it that other programs can update the 
screen contents much faster than when I do it? :)

> Unfortunatly no, I worked with Xlib for 5 years and there is no
> such function. If you want to do resizing yer going to have to use
> RDK RGB buffers soly and `blit' each pixel using your own zooming
> code.


My resizing code is inherited from the previous version of my embedded 
system. I wrote that code in C initially, then went through and 
hand-optimized it in assembler. The processor we used in that old 
project is a PA-RISC Level 1 core with some proprietary SIMD extensions. 
My extensions - the actual shipped code - use those extensions, and the 
C version is comparatively slow (and also buggy, and hard to understand 
because it has to take care of a bunch of special cases). After I got 
the asm version working, I only kept updating that version, not the C 
version.

I was hoping that some guru had written better code I could use.


> > One of the other reasons I wanted to move to pixmaps is that they are 
>
> Move? You said resize?


Yes, I meant I wanted to shift my program to operating primarily out of 
pixmaps.


--
-- Lewin A.R.W. Edwards (Embedded Engineer)
Work     http://www.digi-frame.com/
Personal http://www.larwe.com/
Tel (914) 937-4090 9am-6pm ET M-F