On Tue, 6 Dec 2005 00:36:53 -0500 Jose O Gonzalez <[EMAIL PROTECTED]> babbled:
> > > On Sat, 3 Dec 2005 19:03:17 +0900 Carsten writes: > > On Fri, 2 Dec 2005 01:06:25 -0500 Jose O Gonzalez <[EMAIL PROTECTED]> > > babbled: > > > > > > > > > > > > > > > Just some attached evas stuff.... > > > > > > > > > > > > > ok jose. i hate to do this.... can you > > > > > > > > 1. generate a diff: > > > > > > > > cd evas > > > > cvs update -dP > > > > cvs diff -U > ~/my_changes.diff > > > > 2. any "new" added files... > > > > > > > > > Attached it is :) There have been many changes to evas > > recently, > > > and here are yet more -- new blend funcs implementations, some > > 'tweaks' > > > to the scaling funcs, a few other minor things..., and fairly > > extensive > > > additions to evas' gradients capabilities.. > > > > > > I can go over them in detail later if desired, but for now > > let's > > > just get this sent before CVS evas changes again :) > > > > > > As always, you are free to do with this as you like, but > > understand > > > that nothing here has been checked or tested. > > > > ok. first. some style things... > > > > 1. dont do: > > > > int var = x; > > int blah = 10; > > > > do: > > > > int var; > > int blah = 10; > > > > var = x; > > > > basically DONT declare values of variables at declaration time, > > unless its a > > constant. > > > > 2. bracets. use them. > > > > do NOT do > > > > a + b * c >> 8; > > do NOT do > > a + (b * c) >> 8; > > DO: > > a + ((b * c) >> 8); > > > > i found some mistakes in your code that made the c fallbacks for the > > scaler > > code for upscaling images break due to lack of brackets. :) > > > > Indeed, yes good point. I usually adhere to this quite rigorously, > but as the hour grows late and the mind weary, my fingers tend to seek > the path of 'fewer keystrokes' it seems... > This is just one reason why it's so important to go over things > and test them -- preferably to have someone else check things as well. > Unfortunately, for this 'stuff', I was serious when I told you that > I hadn't a chance to check the blending or scaling funcs :( yeah. it's fixed now anyway. thanks :) > > otherwise... > > > > good job! the gradients looke funky. very nice :) > > > Funky? Nah, quite conservative. But it should allow for most of > what is needed for svg gradient support (I need to add another type of > tiling/spread mode - "PAD" - the simplest one.. which I just forgot to > get to). yeah - we ALSO need arbitratry clipping to any object, with an added option of pre-rendering all objects to be clipped by a clipper to a tmp buffer, unlike the current system where it clips AS it renders (both are useful), path objects (polygonal are there, but need bezier) for being able to clip to a path... :) > There are "issues" with some things - it could be much more > optimal in some areas, and the filling just slams the color that > fits the integer part.. this is for speed reasons, as one should really > interpolate (as is done on 'edges') when aa, etc. > And of course the GL engine is broken :( Will try to deal with > it later if no one else does.. that's ok for now. gl is not a priority engine. if i were to have oit all - i'd love all engines to be equal, but that won't happen, so priority is software_x11, buffer, fb and xrender_x11 (the first 3 share the same routines so its rewally just a painful matter of adding api calls). > > and yes the evas > > benchmarks > > went up a bit - i did soem fiddling too myself. :) > > > Noticed that.. very nice :) > > BTW - Re the mm7 issue.. Recall sometime ago I once mentioned to > you that I'd experienced a similar phenomenon... yeah. it's bizarre. mm7 just.. loses its 0 value. i don't know why. i guess i SHOUDl chekc the assembler output. weird. > It's possible that this is being used 'behind our backs' to hold > some intermediate values, maybe try using mm6 instead and see if that > remains stable. it COULD be - but it shouldn't be. the mmx registers should be all free for us to use.... hmm... > Also, in the 'evas shutdown' function, there's no need to call > the evas_font_dir_cache_free function, this is already called in the > evas_common_shutdown function I introduced :) the common shutdown is for the common engne -t he font dir cache is actually outside the common code (core part of the canvas layer) - i shoudl strip it from the common shutdown i guess :) > > > Ready for more 'stuff'? uh oh - just recovering from the last one! i did end up spending almot all of my saturday on it :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
