On Mon, 14 Mar 2011 10:49:10 +0900 "Sung W. Park" <sung...@gmail.com> 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? :) > > 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? > > 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 :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
