On Thu, 26 Feb 2015 22:13:15 +0000 Branko <bran...@s5tehnika.net> said:
> Dne 26. 02. 2015 ob 20:34 je Cedric BAIL zapisal(a): > > Yes. You can easily get and modify the pixels of an Evas_Object_Image > > the way you want. Go to > > https://developer.tizen.org/dev-guide/2.3.0/org.tizen.mobile.native.appprogramming/html/guide/ui/evas_guide_image.htm > > and search for "Setting Raw Data to Image Object". > > Many thanks. I will look into that. > > > > > No, Evas is a scenegraph. It does manage all the rendering of all the > > primitive object in the best possible way. If you have idea on how to > > improve rendering, that's where you should actually play :-) Also for > > now, we don't have any scenegraph object for vector graphics, but we > > are just working on it right now and may push that forward in the next > > 1.14 release. You can look at my branch, devs/cedric/evas_vg to see > > what I mean by that. Actually if you had feedback on what you are > > looking for in a vector API, it would be really interesting. Regards, > > Problem with scenegraphs is that they have to be copied into final > frame, which wastes bandwidth. I was thinking that in some circumstances > it could be done so that: they do not need to be copied. scene graphs have nothing to do with copying. that is simply one way of getting data somewhere. evas's renders use various methods to get data from a to b depending on situation and available mechanisms. the fb renderer that uses fbcon does indeed copy - it does this to avoid seeing the rendering happening while scanout happens. we could have set up fb panning and render to the offscreen buffer then "flip" when done, but it wans't a key issue and requirement as fb engine is rarely used. the software_x11 engine may copy (xshmputimage) or it may even use drm/dri2 to do zero copy swaps (render to backing buffer directly, when done, swap buffers). the gl rendering engine is the same. a swapbuffers is up to the driver to implement (it may copy or swap depending on what it feels like doing), but assuming it swaps, we render to backbuffer then zero-copies to display. if you have enough extensions in egl/glx we can even do partial buffer renders to only render the areas that need updating. same with wayland as a display target... etc. so no. copies have nothing to do with a scene graph. :) > - copying is avoided > - frame drawing is merged with scanning. That is, one could read data this is basically impossible. it requires your rendering be AT LEAST as fast as scanout requires. as scanout is (in most cases) fixed, you have to scan out a line in an exact given timeframe, and that is unfortunately not possible to do with rendering ad time to render will depend on complexity of operations. so basically this is a "pie in the sky" idea that unless you have a rediculous amount of rendering grunt vs scanout timing requirements... is not going to happen. > and modify it just before it is to be scanned and sent to display. That > way, data read is in the cache and can be read from there by picture > generating circuitry. It also changes the way primitives are drawn - > scanline by scanline. > > As I understand, under Wayland there is a way to work with a window > frame without it being copied to main picture frame. > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
