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

Reply via email to