On 04/08/2016 12:17 PM, Carsten Haitzler (The Rasterman) wrote: > On Thu, 7 Apr 2016 20:43:28 +0200 Andreas Volz <[email protected]> said: > >> Am Thu, 7 Apr 2016 08:14:29 +0900 schrieb Carsten Haitzler (The >> Rasterman): >> >>> On Wed, 6 Apr 2016 22:25:09 +0200 Andreas Volz <[email protected]> >>> said: >>> >>>> Am Tue, 5 Apr 2016 11:01:51 +0900 schrieb Carsten Haitzler (The >>>> Rasterman): >>>> >>>>> On Mon, 4 Apr 2016 23:34:47 +0200 Andreas Volz >>>>> <[email protected]> said: >>>>> >>>>>> Am Mon, 4 Apr 2016 13:30:15 +0900 schrieb Carsten Haitzler (The >>>>>> Rasterman): >>>>>> >>>>>>> On Sun, 3 Apr 2016 22:15:19 +0200 Andreas Volz >>>>>>> <[email protected]> said: >>>>>>> >>>>>>>> Am Fri, 1 Apr 2016 16:31:42 -0700 schrieb Cedric BAIL: >>>>>>>> >>>>>>>>>> I tried to start my application with the default Gtk >>>>>>>>>> based window manager, but it's strange. As long as I >>>>>>>>>> activate alpha and shaped window support in my >>>>>>>>>> application the application is somehow broken and hangs >>>>>>>>>> in the beginning. I didn't yet trace it out where it >>>>>>>>>> hangs. >>>>>>>>>> >>>>>>>>>> Do you have any ideas or explanations? >>>>>>>>> >>>>>>>>> Not for the last problem. >>>>>>>> >>>>>>>> I didn't change much in my application, but now I get a >>>>>>>> crash of E20 and X back to the console if I start my >>>>>>>> application on the Raspberry Pi. >>>>>>>> >>>>>>>> In LXDE it still just hangs my application at the point it >>>>>>>> starts the window. Need to start my application in the >>>>>>>> debugger and see where it exact hangs. >>>>>>>> >>>>>>>> See here the E crash dump: >>>>>>>> >>>>>>>> http://tux-style.com/tmp/e-crashdump.txt >>>>>>> >>>>>>> like 633? that's in bgr565 - 16bit handling. this will cause >>>>>>> even more slowness as e has to use efl to convert 16bpp to >>>>>>> 32bpp then render in 32bpp then render/dither back to 16bpp >>>>>>> for the display... >>>>>> >>>>>> Ok, have I influenced this in my application setup? >>>>>> >>>>>>> try 24/32bpp for best results. but anyway. this says the 16bit >>>>>>> converter has a bug maybe - > thats s16 (src 16bit) ptr - and >>>>>>> it uses sbpl to multiply y + row.... so what's up with this? >>>>>>> sbpl is src bytes per line. so 640 there. i assume its a 320 >>>>>>> wide window then. is y and row ... wrong? row is the current >>>>>>> row we are looking at? y + h >>>>>>>> image height? height says it's 240. row is 0... src pts and >>>>>>>> s16 are the same - so that's right. ... so it's not src. dp >>>>>>>> (destination pointer) is the issue. in >>>>>>> fact see dst - its NULL. (0x0). thats the issue. why is it >>>>>>> null? that's odd. :( >>>>>> >>>>>> No my window is 800x480 pixels big. Maybe that's the LXTerminal >>>>>> size. I had two terminals open at this time. >>>>> >>>>> well the backtrace deals with a window that is 320 wide... and >>>>> data is null to write the grabbed data (converted data from >>>>> rgb565 to 32bit agb8888) to.. and that is super odd. >>>> >>>> I attached gdb when the crash dialog comes up. This is the result. >>>> Maybe it helps. >>>> >>>> http://tux-style.com/tmp/e_backtrace.log >>> >>> same problem there too. dest pixel buffer is NULL. thats why it >>> crashes. i don't know why it's null. evas_object_image_data_get() is >>> obviously returning NULL. why? is image size 0x0? has something else >>> happened? e's code doesnt handle a null return there - so thats why >>> the crash. so you'd get garbage or blank/black instead if e did... >>> >>> e_comp_object.c:e_comp_object_render() >>> >>> pix = evas_object_image_data_get() <- there >>> >>> why is it null? is is because it was even set to null? i don't know. >>> i haven't seen this happen with e under xephyr... >> >> But xephyr is a good hint. For sure I use this also on my development >> pc. So I installed it on my Raspi and tried the same. I get an E >> crash just if I start *ANY* application window inside. Interesting is >> that Xephyr and the application is still living and usable after the >> crash in this setup. E own windows like e.g. the file manager are >> working. >> >> I don't understand this. I'm thinking of removing all binaries and >> install everything again - just to be sure. :-( >> >> BTW: I used these releases: >> >> econnman-1.1 emotion_generic_players-1.16.0 terminology-0.9.1 >> efl-1.16.1 enlightenment-0.20.1 >> elementary-1.16.1 evas_generic_loaders-1.16.0 >> >> Do you think there's a chance this is working from GIT? > > it should... i see no reason it should not. :/ >
enlightenment 20.6 has lots of Fixes for crashes and other issues but there is also a few more fixes in git so 20.6 could be worth testing if you want a little more stability. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
