Hi, On 31.03.2014 04:06, Harvey wrote: > I'm still a little confused as to why the move to lgi was considered to > be necessary at all. [...]
I never liked some of the hacks that the widget layout code needed to do. It got some nested tables containing widgets as arguments and had to return a flat table whose indices was matched with the widgets via a depth first search through the widgets table. Do you remember having to use ".widget" to make progressbars and graphs (and other things?) behave? Without that, they would ignore the layout and always be put at the left side of the wibox. I think originally the move to some lua-cairo-bindings started with "Make or image API more powerful by using cairo bindings": https://awesome.naquadah.org/bugs/index.php?do=details&task_id=757 (Oh and of course the new widget system existed and is in git since 2010, but no one ever complained until v3.5 aka december 2012 aka two years later :-/ ) > I presume all of these X11 round trip calls and blocking issues existed > in 3.4 branch for some time, but what does 3.4 do / utilize that is so > much more efficient that lgi does not? Is it truely impossible to retain > the new layout functionality and revive, if not in part some older 3.4 > components? [...] In 3.4, the C API implemented three widgets. There were textboxes, imageboxes and the systray. Nothing else. Some lua code was called when necessary with the widgets table and the available size as arguments and it calculated the position and size of each widget. There was the image API. This allowed to create images, draw (axis-aligned?) lines and fill rectangles. Really powerful stuff... Not. The C code then used all this information to do the actual drawing with cairo and pango from C. So there was a really low overhead per call for the actual drawing. With 3.5, the C code just exposes a cairo surface to lua and all the drawing is done in lua. Everything else is done in lua. So, for example, the progressbar and graph widgets are now less of a hack. AFAIK the higher cpu usage comes from a much higher per-call overhead for each cairo and pango function that is called. But there are likely also some things were we do more work than strictly necessary. Cheers, Uli P.S.: During a blocking round trip (or sleeping for other reasons), a process doesn't use the CPU. So this doesn't contribute to any CPU usage. P.P.S.: I wonder how oocairo compares to lgi, performance-wise... -- "In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move." -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
