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 <li...@brachttal.net> > 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 > > > <li...@brachttal.net> 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 > > > > > <li...@brachttal.net> 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? regards Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
