[Gzz] Re: 1st

[Tuomas Lukka]

On Mon, Jul 01, 2002 at 11:09:01PM +0300, Tero Mayranen wrote:
> On Fri, 28 Jun 2002, Tuomas Lukka wrote:
> 
> > Yes, exactly. The pixbuf we're loading is a scrollblock, and different vobs
> > may want different portions of it.
> >
> > I'm not sure when the right time to load it into a texture is, especially
> > since we may want to load different levels of detail separately: if it's 
> > only
> > seen from afar, only load a 32x32 thumbnail.
> 
> OK.....  There used to be talk about the mediaserver doing those
> thumbnails to save network bandwidth...?  but now, since the
> sync is done "beforehand", it's done by the backend to save graphics card
> memory?  If we wanted to save bandwidth then we'd want a really smart
> cache in the backend, but if that's not the objective this time, then we
> don't need it that much...  Right? =)

Very good point. We do need a place to plug that functionality in when we want.
It's not done to save graphics card memory only but memory and disk bandwidth 
as well: imagine us having 1000 pages at 1500x2400 pixels each. And a LOT of 
them
visible at the same time, although most small. With this, we REALLY need to
use the low-resolution images to ensure that we keep responding to user actions
quickly.

The point is that it's perfectly ok to show a 32x32 thumbnail zoomed up and 
replace
it with the real thing as it becomes available, but showing nothing would be 
really
bad.

> > > The ImageProducer/Consumer-interfaces sound
> > > oddly appropriate, but we probably don't want to send the pixbuf back to
> > > Java just to be sent back to OpenGL, so we'll need to do an
> > > ImageProducer/Consumer-thing in C++, right?  .. hmm, I'll try to draw that
> > > diagram =)
> >
> > Not necessarily, since the textures need to be shared.
> 
> OK, updating the shared OpenGL pixels will obiviously update all the
> "consumers" automatically...  But do we still need to keep track of them
> manually, so we can tell when there's "no-one looking" anymore?  Hmm OK
> I'm guessing OpenGL is probably smart enough to do that for us...

Not true, unfortunately. OpenGL does no such thing. Note that the textures
are used with integer handles, and OpenGL can't know if you've forgotten
all those handles.

However, for that problem we actually do already have a solution in place
in GzzGL-jni.cxx and GZZGL.java: note how the destructors (finalize()) of
the Java objects work. They delete the C++ object explicitly.


> But what about when one consumer suddenly wants a better level of detail
> than the others?  Do we want many copies with different levels of detail
> (hmm, isn't that called mip-mapping?) 

Yes. Or at least when you provide all the copies with exactly 2x difference
in resolution each time, and the resolutions are 2^n. There's a fascinating
reason for demanding this, having to do with a really cute memory layout,
remind me to explain this when I come to Jkl.

For mip-mapping we will always have those copies so I think it might be ok
just to have the highest-resolution mipmap level change, loading and unloading
them as necessary.

> or do we update all the other
> "consumers" (faces mapped to that pixbuffer) to the better-level image..?
> I'm guessing OpenGL isn't smart enough to do that automatically, but...

> I should read the fascinating OpenGL manual =/

Maybe our group should buy the third edition of the "red book"
(OpenGL Programming Guide)... could you talk to Esa?


> > Well, the question is more: where do the actual images cross the
> > backend-frontend line. See the uml diagrams (run "make doc" after
> > rm -rf CLASSES/* and see doc/Gzz_architecture.html)
> 
> gzz.control.PixbufCopier? =)

Hmm... maybe. Right now I'm thinking about adding a class to gzz.media
that would create the spans, and it would be nice to have the interface there...

It might also make sense to have the method to get the Pixbuf in ImageSpan
itself... However, it's not nice to force everyone to implement that.
Maybe three methods: return java.awt.Image, return pixbuf, return byte[]...

        Tuomas