On Tue, 12 Apr 2016 22:43:27 +0200 Andreas Volz <li...@brachttal.net> said:
> Am Sun, 10 Apr 2016 10:10:04 +0900 schrieb Carsten Haitzler (The > Rasterman): > > > On Sat, 9 Apr 2016 20:10:23 +0200 Andreas Volz <li...@brachttal.net> > > said: > > > > > Am Fri, 8 Apr 2016 20:59:51 +0200 schrieb Andreas Volz: > > > > > > > Hello, > > > > > > > > as I'm so happy I managed to port my OpenInfotainment In-Car > > > > prototype software to Raspberry Pi 2 here are some photos: > > > > > > > > https://drive.google.com/folderview?id=0B3wpqTeeGOAHUVlOT3VuMmdyeWc&usp=sharing > > > > > > > > Everything depends on EFL and E20 itself. All processes are > > > > connected with DBus. I used libosmscout for the navigation map > > > > and cairo in an evas canvas to draw it. The GUI CPU load of the > > > > prototype is ok for the Raspi, so I could continue with the > > > > feature development. :-) > > > > > > > > If you're interested I'll keep you informed about the state of > > > > this project on the list here. > > > > > > > > I didn't yet decide about if I like to use emotion as audio > > > > player. > > > > > > Youtube update: > > > > > > https://www.youtube.com/watch?v=9_zmu2uGu0Y > > > > i thought the scrolling speed was bad (as disucussed - lots of copies > > and conversions on the cpu. if you had a working gl driver this would > > be cut down a lot). you may want to check if "dont composite > > fullscreen windows" is enabled under composite settings in rendering > > in e. > > This is option was yet set. But I now I also call the > elm_win_maximized_set() only for the case there's a difference to just > set the window borderless in max screen resolution size by hand. why not set fullscreen to true? just one thing to swizzle not 2? > ALso I set elm_win_alpha_set(false) as I currently don't need it. Maybe > this even improves. well... if you never set alpha to true... then it is false. yes. it's better to do this. :) > > runing in 16bpp is going to always cause extra conversion. with all sw > > rendering just to get something updated on screen: > > How could I prevent that color conversion part? Should I configure my > window in another way? this depends - xorg options or even kernel boot parameters. maybe its booting in 16bpp. > > client: > > render in in 32bpp > > convert/copy + dither 32->16bpp > > compositor > > copy 16bpp to client > > convert 16bpp to 32bpp > > render in in 32bpp > > convert/copy + dither 32->16bpp > > > > if "don't composite fullscreen windows" is enabled ... your > > fullscreen app can drop all of the compositor part of the pipeline. > > > > if you run in 32bpp. then the conversions are dropped. if you have a > > gpu of course the rendering is done by hw (you do have to ensure the > > client is using gl too - change elementary_config settings to prefer > > some kind of acceleration). you would need to go try the new > > experimental mesa support for the vidcore gpu - it may mean building > > your own... or finding pkgs someone is maintaining that do. > > I'll wait and hope for this and concentrate on my application even if > not at perfect speed. I've enough open points on my side. :-) > > > but scrolling speed. ok... your map rendering updates are like "go > > make a cup of coffee an come back when it's done". :) what is going > > on there? > > I'm in contact with the libosmscout developer. Maybe things could be > improved in the engine itself. For example the routing part. This is > not on my side. Maybe a faster hard disk for map data instead of the SD > card may also help. hmm i doubt a hdd will do better. :) the sd card has zero seek times, and read-speed should beat the hdd - especially since a hdd on a rpi needs to go through usb 2. the sd card has its own dedicated channels. WRITe speed could be horrible. this does happen. you really have to hunt a good sd card/thumbdrive etc. for good write speeds, but read should equal or beat the hdd and have no seek. it might be worth getting a quick profile to see what's going ton. where is the cpu time going? > But for sure my rendering loop itself is so bad. It's just a prototype > that calculate and renders a complete screen with a hard configured > frequency without any image caching or similar. I should just render a > big image and then move it around as the car moves. Cache zoom bitmaps > or pre-render low quality image and blur them to hide longer loading > maps or other tricks to improve the user reaction time. So you see many > points to do until I go to the OpenGL optimization point. actually divide the map into tiles, then just move that grid of tiles around. as you need NEW tiles (eg as tiles are coming close to the screen viewport), spawn off a thread to do wander through osm data, render, then present the results back to the mainloop when ready. mainloop just updates image object pixel data and presto. if your threads are fast enough they can prepare a tile before it becomes visible. :) > regards > Andreas > > -- > Technical Blog <http://andreasvolz.wordpress.com/> > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > 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 ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
