[GEM-dev] gemcvs pix_texture: not using client storage??

[cgc]

On Jan 13, 2004, at 1:44 AM, IOhannes zmoelnig wrote:
> probably "rectangle $1" ?

yeah, sounds fine to me.  any other suggestions?

> we could then turn on/off "special" texturing, like rectangle or 
> client-storage independently, which would also help at debugging.

there's been a 'client_storage $1' message for several months.  you 
have to start and stop rendering manually to have it change though.

just a note about the client storage and DMA stuff on OSX:  as it turns 
out i sorta really fucked it up in a way.  the way it works is by 
eliminating the driver copy of the texture which means that the client 
app has to protect the buffer data itself.  well the GEM way of 
rendering has pix_film doing all the movie tasking before pix_texture 
sets up and calls the texture upload, and that creates some problems.  
you might have noticed some texture corruption on OSX especially when 
doing any UI actions while a film is playing - that's when GEM is not 
protecting the buffers.  so the near term fix has me writing a new 
pix_movie object that's coded from the ground up for this special case 
and it calls the QT tasking _after_ the texturing.  so far it works 
fine, and it will be a good option for those that want to play lots of 
.movs at once or just get video to screen as fast as possible.

pix_texture is going to have client storage turned off until i figure 
out a fix.  the fix i have in mind is to simply pass the qt movie data 
as part of GemState, and have pix_texture do the tasking.  the might 
have the added benefit of allowing other objects access to the QT data, 
and thus avoiding the god-awful 242.film hell of a thousand million 
messages.


> and i have thought of finally rolling in the stupid teapot, this is: 
> copy'n'paste the code from glut so we don't have that dependency any 
> more.
> what do we need the teapot for ? still a cool complex object for 
> testing, and it is the standard 3d-object.

oh, i thought we decided to get rid of that teapot ages ago?  it's 
funny for demos, but you're right - what's the point?  anyway, i have 
the mesa glu source now and will probably set about doing some of the 
coding tomorrow.  i've got the glu objects and model to change texcoord 
handling, and pix_movieDarwin to finish up, which could either go in 
the almost mythical 0.888 or wait.

cgc

>
> mfg.asd.r
> IOhannes
>