On Fri, 25 Mar 2011 15:46:41 +0900 "Sung W. Park" <[email protected]> said:

> oh great!  I guess you finally got around to it =)

yeah... today is "catch up" day :)

> On Fri, Mar 25, 2011 at 1:57 PM, Carsten Haitzler <[email protected]>wrote:
> 
> > On Mon, 14 Mar 2011 10:49:10 +0900 "Sung W. Park" <[email protected]>
> > said:
> >
> > > Ah, i see that you finally had a chance to go through your email piles =)
> > > welcome back!
> >
> > and now... another email pile is being conquered... i hope :)
> >
> > > > gl_x11_evas_engine.patch:
> > > > surprisingly... i have very little to grumble about. the only thing is
> > the
> > > > hash
> > > > thing where you comments "i didn't think it was necessary...". as such
> > you
> > > > can
> > > > get away with not doing it until you try and duplicate the same texture
> > in
> > > > multiple image objects. the compositor does this - or can do it (and it
> > is
> > > > used
> > > > for some effects like exposee).  this means it will share the same gl
> > image
> > > > wrapper struct etc. etc. which saves some resources.
> > > >
> > > > what you need to do here is put the image in a hash - like the one that
> > > > uses
> > > > pixmap id, but here using texture id. so u'll need another native_hash
> > so
> > > > that
> > > > id's dont clash (tex id vs pixmap id) and then put it in there and take
> > it
> > > > out
> > > > of it just like the native_hash stuff is done for pixmap id's. :)
> > >
> > > my thoughts were that it wouldn't be a big overhead to just create new
> > image
> > > objects
> > > for each texture reference but you're right in that it does save
> > resources
> > > if you reference them.
> > >
> > > by the way, is there a good way to create a unique ID that i can use for
> > > hashing?
> > > since pixmap IDs are globally unique, it's good to use it as hash keys
> > but I
> > > think using
> > > texture IDs would be a bad idea since it's context specific.  any
> > thoughts
> > > on that?
> >
> > hmmm as such there HAS to be a unique Id for evas's gl context anyway...
> > and
> > that text id will have to be unique as otherwise evas's context cant
> > identify
> > one texture from another... so this id is.. sufficient... is it not? :)
> >
> 
> Yes i've realized that and wrote a response in another email.  I've handled
> it in the patch
> that I last sent.

was walking my mails... saw it later :)

> > > > now as for target GL_TEXTURE_2D ... vs what?
> > GL_TEXTURE_RECTANGLE_NV/ARB
> > > > etc.?
> > > > i'm not sure that's entirely wise? 1D and 3D textures would need proper
> > > > handling then too. also rectangle textures are subject to a different
> > > > coordinate space (in pixels vs 0.0 -> 1.0). right now the gl engine
> > core
> > > > doesn't use/handle these at all actually. i'm not entirely sure we need
> > > > to/should as rectangle textures come with a whole bunch of
> > > > gotchas/limitations,
> > > > and there are standard npot textures around anyway. :) i'm not really
> > sure
> > > > any
> > > > client would need/want to do this?
> > >
> > > the thought of having texture target came after seeing #ifdef
> > > GL_TEXTURE_RECTANGLE_ARB
> > > in the code.  If you tell the user that
> > evas_object_image_native_surface_set
> > > only
> > > supports GL_TEXTURE_2D then I guess not having it would be fine.
> >
> > well that';s kind of "codd i might have implemented, but in reality it
> > means
> > dealing in 0.0->1.0 coords vs 0->N coords, and as its not universal, we
> > need to
> > do both.. and anyone that seems to do rectangle textures these days also
> > handles npot textures. if they only do pow2 they seem to avoid rectangle
> > textures"... so... i don't expect rect textures to be used... your
> > thoughts?
> 
> I think it's fine.  rect textures are nice to use for multi-pass rendering
> in my
> opinion but, i think it's ok to assume regular texture  2D for now?

i'd say so. :)

> > > > so if you can fix the hash thing... that'd be good. the yinvert patch
> > is
> > > > already in svn, so just send an update on the other stuff as above :)
> > > >
> > > >
> > > I'll do that once I get your response about the hash id.
> >
> > above :)

> 
> the last patch that i sent already has the above fixes so i'll apply the
> other suggestions/comments that you have from the other email responses
> before i send an updated patch.

yeah. do that :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [email protected]


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to