oh great! I guess you finally got around to it =) On Fri, Mar 25, 2011 at 1:57 PM, Carsten Haitzler <ras...@rasterman.com>wrote:
> 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? :) > Yes i've realized that and wrote a response in another email. I've handled it in the patch that I last sent. > > > > 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? > > > > 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. > -- > ------------- 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
