Hi,
I've committed the patch including the Image::imageContentChanged
function which simply goes through all parents and if one is a
TextureChunk calls the imageContentChanged function of it.
So, to summarize:
- If you change the contents of the whole image, the TextureChunks are
notified automatically.
- If you change a part of the image content, the TextureChunks are
notified, but it is more efficient to explicitly call either
TextureChunk::imageContentChanged or Image::imageContentChanged and
specify the region that was modified.
- If the size of the image changes (requiring a reinit instead of a
refresh of the OpenGL texture object), the TextureChunks are notified
automatically.
Thanks for your comments and input on this issue,
Carsten
On Fri, 2007-08-24 at 10:11 -0500, Dirk Reiners wrote:
> Hi All,
>
> Marcus Lindblom wrote:
> >
> > From a user perspective I'd rather not have image-updating knowing
> > about texchunk at all, but I agree we shouldn't break 1.x code.
>
> Yes, breaking 1.x code is not really an option.
>
> > If this patch is applied to 2.0 too, breaking code there might be worth
> > it, no? (See below for an idea to move this function to Image
> > altogether. If we do that, we could remove it from TextureChunk, as it
> > would be redundant.)
>
> Sounds ok to me.
>
> > True. It would perhaps make sense to change this in Image. That would
> > also improve performance for clustering when image-pixel-data is
> > transferred. I don't know if that's a common case though, but if it is,
> > adding "dirty rectangle" logic to Image might be worth it. This might be
> > best put in a new ticket.
>
> I can't think of a common case for it, really.
>
> > True. That would work, and it'd be spiffy if you could do this through
> > the parents field. Perhaps it would make sense to put a
> > imageContentChanged() function in Image, that forwards this call to all
> > texturechunk parents?
>
> Good idea. We could do that for 1, too, while keeping the TC one for
> backwards
> compatibility but deprecate it.
>
> > This sounds like a good idea. Do we need separate functions to set and
> > extending the dirty area, with extending being the default, or is that
> > too complex?
> >
> > This means we can also, in the future, enhance this to to update a few
> > small areas separately, should anyone need that. (I'm thinking large
> > virtual textures, etc). Your proposal is compatible with that.
>
> True, but I'm a little worried about the effort required for making it work
> reliably vs. the number of uses this feature is going to get. I'm having a
> hard
> time coming up with good examples that would benefit from it. I definitely
> wouldn't do it for 1, but we could open a ticket to consider it for 2.
>
> Dirk
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Opensg-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
