On Tue, 26 Jul 2016 07:33:08 -0700 Chris Michael <[email protected]> said:
> devilhorns pushed a commit to branch master. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=ab1c2ed5d128c8a0e3fad1c7499ad511e290073d > > commit ab1c2ed5d128c8a0e3fad1c7499ad511e290073d > Author: Chris Michael <[email protected]> > Date: Tue Jul 26 10:31:03 2016 -0400 > > Revert "e - fix major memory bloat when in gl mode - dont create shm > segments" > This reverts commit ae6e09ec11aebdce47aba0e18d8aad0368c2f101. > > This breaks resizing of windows inside Enlightenment. Evas_Engines > don't bind a pixmap permanently, they just bind during each render, so > on resize this caused a broken pixmap if we don't create a new one for > each size. This patch Would be correct IF engines worked differently > wrt x pixmap binding during render. ARGH! then e's compositor has been badly broken since zmike xchanged it to do this e_pixmap thing. e ALWAYS creates an ecore_x_image for EVERY window ALL the time ALL day long, if needed or not. when using texture from pixmap it is not needed. this is the accelerated non-software-fallback case. it is NOT needed unless the window is shaped (or texture from pixmap is turned off). that means 10's of Mb of memory being allocated (but not actually touched) in shared memory all day irrespective of need. this creates huge problems especially when shared memory is limited. on linux i think the limit is 256M. on openbsd it's 32M. (by default). the code there is obviously wrong totally wrong. it should ONLY exist when either it's a shaped window and we have to fall back to messing with pixel data ourselves OR texture from pixmap is off and/or we're in software. e_pixmap has no clue which is the case though as it can't get access from the e_pixmap to the comp struct. > --- > src/bin/e_pixmap.c | 26 ++++++++------------------ > 1 file changed, 8 insertions(+), 18 deletions(-) > > diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c > index 921cc06..febb689 100644 > --- a/src/bin/e_pixmap.c > +++ b/src/bin/e_pixmap.c > @@ -830,7 +830,12 @@ e_pixmap_image_refresh(E_Pixmap *cp) > { > case E_PIXMAP_TYPE_X: > #ifndef HAVE_WAYLAND_ONLY > - return EINA_TRUE; > + if (cp->image) return EINA_TRUE; > + if ((!cp->visual) || (!cp->client->depth)) return EINA_FALSE; > + cp->image = ecore_x_image_new(cp->w, cp->h, cp->visual, > cp->client->depth); > + if (cp->image) > + cp->image_argb = ecore_x_image_is_argb32_get(cp->image); > + return !!cp->image; > #endif > break; > case E_PIXMAP_TYPE_WL: > @@ -899,20 +904,6 @@ e_pixmap_image_is_argb(const E_Pixmap *cp) > return EINA_FALSE; > } > > -static Eina_Bool > -_e_pixmap_image_alloc(E_Pixmap *cp) > -{ > - if (cp->image) return EINA_TRUE; > - if ((!cp->visual) || (!cp->client->depth)) return EINA_FALSE; > - cp->image = ecore_x_image_new(cp->w, cp->h, cp->visual, > cp->client->depth); > - if (cp->image) > - { > - cp->image_argb = ecore_x_image_is_argb32_get(cp->image); > - return EINA_TRUE; > - } > - return EINA_FALSE; > -} > - > E_API void * > e_pixmap_image_data_get(E_Pixmap *cp) > { > @@ -922,7 +913,7 @@ e_pixmap_image_data_get(E_Pixmap *cp) > { > case E_PIXMAP_TYPE_X: > #ifndef HAVE_WAYLAND_ONLY > - if (_e_pixmap_image_alloc(cp)) > + if (cp->image) > return ecore_x_image_data_get(cp->image, &cp->ibpl, NULL, > &cp->ibpp); > #endif > break; > @@ -973,8 +964,7 @@ e_pixmap_image_draw(E_Pixmap *cp, const Eina_Rectangle *r) > { > case E_PIXMAP_TYPE_X: > #ifndef HAVE_WAYLAND_ONLY > - if (!cp->pixmap) return EINA_FALSE; > - if (!_e_pixmap_image_alloc(cp)) return EINA_FALSE; > + if ((!cp->image) || (!cp->pixmap)) return EINA_FALSE; > return ecore_x_image_get(cp->image, cp->pixmap, r->x, r->y, r->x, > r->y, r->w, r->h); > #endif > break; > > -- > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
