[E-devel] Minor evas fix for clips
Just discovered an interesting issue with evas:
evas_object_clip_set(obj,obj) is all bad.
This one line fixes the problem (which is mostly a PEBKAC, but still).
--- src/lib/canvas/evas_clip.c 16 Nov 2006 03:20:24 - 1.26
+++ src/lib/canvas/evas_clip.c 12 Apr 2007 02:48:10 -
@@ -169,6 +169,7 @@
return;
MAGIC_CHECK_END();
if (obj->cur.clipper == clip) return;
+ if (obj == clip) return;
if (obj->smart.smart)
{
if (obj->smart.smart->smart_class->clip_set)
Regards,
nash
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] clientlist menu config panel change...
On 04/08/2007 23:39, Ravenlock wrote: > Hello, > > Attached is a small patch which will add a check box to the config panel > that manipulates the clientlist menu. > > Presently there is a way to limit the length of the caption of > clientlist menu items. However if you do not wish to limit the length > you would need to set the limit to 0. It's occurred to me that this may > not be the most intuitive for a user... So I've added a checkbox which > will allow them to clearly enable or disable the feature. > > If there are no objections... I'd like to commit this. No objections noted. In CVS. :) > > Questions, comments, and complaints welcome. > > > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards, Eric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
> > But the 'problem' goes deeper than that. Right now the > > argb data itself (ie. the result of loading things given only > > the file/key/load_opts combo) may be shared by several cached > > engine images, ie. images which have the same file/key/load_opts > > but could have different 'displays' say, and this is the real > > source of the 'problem'. > > I am not sure if I understand correctly the problem. As I currently > implemented my cache mecanism, a RGBA_Image could only end in one > image cache linked with one engine and one cache_key. Now what we > want, is having one RGBA_Image in multiple cache linked with multiple > engine, but with one cache_key. This cache_key should only be the > same if all engine are really ok to share this RGBA_Image. Is it > correct ? > In that case, I need to provide a way to request each engine > to compute the cache_key and if they all give the same answer, > it's ok (I take for granted the fact that I could have multiple > cache for one RGBA_Image. I know, it will need some thinking also). > Or did I miss a bigger problem ? E... I think if I try and explain this again I'm likely to cause more confusion. :) Take a quick look at eg. the xrender-x11 and gl image cache related stuff. Every engine 'image' needs to keep at least argb32 data that one can load/set/get from the canvas api. It also may want to keep such data in engine specific buffers of some sort (if it can composite such to the dst target surface via some means it posseses -- in your sdl engine case, you're not using any sdl provided functions for compositing, so you can't really benefit from keeping loaded data in sdl surfaces). But these engine specific buffers may require some form of differentiation, apart from the argb32 data they are made to hold. Now, for 'loading', one wants to be able to keep as few copies of the argb32 data as possible - regardless of the number of canvases, the type of engines, the means the engines are using for holding the data, etc. So, what are you going to do if you want to load file "blah" ONLY ONCE, but maybe use its argb32 data in many canvases, which may be using many different engines, some of which may want to hold that data in 'surfaces', which may need to be created in some particular way, dependent on engine info (even though they take the same loaded argb32 data as input - no making copies of the loaded data allowed either). ??? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wednesday 11 April 2007 09:41:22 [EMAIL PROTECTED] wrote: > Cedric wrote: > > > this is why there is a specific engine copy wrapping the image > > > - the RGBA_Image just acts as a source of RGBA pixel data. > > > the wrapping engine image colds a pointer to that plus engine > > > specific data. the image is also looked up not just by filename > > > + key, but ALSO by engine specific properties too. > > > > When I did take a look at others engines, I missed such idea. > > So I didn't take them into account for the cache. I will need > > to think how I could solve that, but I would like to try to solve > > this on a real case. Do you have an engine that need more than > > one private data ? (One that could be a good start to see, > > understand and fix this problem) > The xrender based engines. The loaded data is kept in > 'pictures', which are resources that depend on other X stuff. > That part would be easy to fix in what you have: add a > function prototype to generate the 'cache_key' from given input > (file, key, load_opts, void *engine_data). Thanks, that should be easy. > But the 'problem' goes deeper than that. Right now the > argb data itself (ie. the result of loading things given only > the file/key/load_opts combo) may be shared by several cached > engine images, ie. images which have the same file/key/load_opts > but could have different 'displays' say, and this is the real > source of the 'problem'. I am not sure if I understand correctly the problem. As I currently implemented my cache mecanism, a RGBA_Image could only end in one image cache linked with one engine and one cache_key. Now what we want, is having one RGBA_Image in multiple cache linked with multiple engine, but with one cache_key. This cache_key should only be the same if all engine are really ok to share this RGBA_Image. Is it correct ? In that case, I need to provide a way to request each engine to compute the cache_key and if they all give the same answer, it's ok (I take for granted the fact that I could have multiple cache for one RGBA_Image. I know, it will need some thinking also). Or did I miss a bigger problem ? Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
Cedric wrote: > > this is why there is a specific engine copy wrapping the image > > - the RGBA_Image just acts as a source of RGBA pixel data. > > the wrapping engine image colds a pointer to that plus engine > > specific data. the image is also looked up not just by filename > > + key, but ALSO by engine specific properties too. > > When I did take a look at others engines, I missed such idea. > So I didn't take them into account for the cache. I will need > to think how I could solve that, but I would like to try to solve > this on a real case. Do you have an engine that need more than > one private data ? (One that could be a good start to see, > understand and fix this problem) The xrender based engines. The loaded data is kept in 'pictures', which are resources that depend on other X stuff. That part would be easy to fix in what you have: add a function prototype to generate the 'cache_key' from given input (file, key, load_opts, void *engine_data). But the 'problem' goes deeper than that. Right now the argb data itself (ie. the result of loading things given only the file/key/load_opts combo) may be shared by several cached engine images, ie. images which have the same file/key/load_opts but could have different 'displays' say, and this is the real source of the 'problem'. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
