flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject RE: Scroller optimization
Date Sun, 26 Oct 2014 11:03:43 GMT
What you did seems very interesting, did you think about publishing your code and/or a demo,
I guess it would help if you want some helps.

Frédéric THOMAS

> Date: Sun, 26 Oct 2014 01:11:01 -0700
> From: vincent@after24.net
> To: dev@flex.apache.org
> Subject: Re: Re:Scroller optimization
> Hi DarkStone,
> Thank you for your response.
> *
> /Instead of using the scrollRect property of the viewport, the ViewportCache
> performs the scrolling of the bitmap version of the viewport using the
> blitting technique which is way much faster.
> What do you mean by "the blitting technique"? Could you explain it in
> detail?/*
> This technique involves a bitmap canvas on which blocks of bits are copied (
> wikipedia <http://en.wikipedia.org/wiki/Bit_blit>  ). Here, the canvas is a
> Bitmap whose dimensions are equal to the viewport ones. The actual viewport
> is rasterized in a BitmapData using the draw method. The viewport is
> rendered using the copyPixel method of the bitmap canvas (copyPixels is very
> fast).
> *
> /the total number of pixels of a BitmapData cannot exceed 16,777,215 pixels,
> although it's large enough, it has its limit./*
> My ViewportCache has a ViewportRasterizer class which performs the
> rasterization work : the rasterized version of the viewport is stored in a
> vector of BitmapData objects with a maximum size of 2880 x 2880. This way,
> even very larges viewports can be rasterized in multiple tiles (a Vector of
> Rectangles is used to store the position and size of each tile). I made some
> tests on my nexus 4 with a 480 x 28 000 pixels viewport and it works at a
> steady 60 fps when cacheViewport = true
> *
> /I would rather create a subclass of Group named "CachableGroup", define two
> properties for CacheableGroup: viewport:IViewport (default property) and
> viewportCache:IViewportCache, then set Scroller.viewport to CacheableGroup.
> The viewport property is like the actual viewport of yours…/*
> I choose to integrate the viewportCache inside the scroller component so
> that the user can leverage the optimization without having to change his
> code (just set a property to true). Furthermore, it's easier to know when
> the throw effect is complete when the optimization is implemented inside the
> scroller.
> *
> /and I also would rather set the viewport or the viewportCache's visible to
> false than using removeElement() when you don't need one of them. Cuz if you
> need to show one of them (the viewport or the viewportCache) back again, the
> addElement() method will have to take some time to render it, it's much
> slower than setting its visible from false to true./*
> Yes, this is the problem. At first I used the visible property to hide the
> actual viewport during scroll operations but this method has a significant
> impact on performance. I'm not sure about the cause but the fact that the
> viewport remains on the display list even if it's not visible hurts
> performance. That's why I choosed to remove the viewport from the scroller
> skin during scrolling, in this case, performance is optimal but then, the
> time needed to add it back when the scrolling is complete can be very long.
> Does the runtime renders every display objects added to the display list
> even if their visible property is set to false ? is the decrease in
> performance between the two approaches is due to the the scroller component
> ?
> I will make some tests with scout to see if I can identify the difference.
> If this problem can be solved, this optimization will have a huge impact on
> scrolling performance (as I said before, I was able to scroll enormous views
> at 60 FPS using this technique).
> Vincent.
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Scroller-optimization-tp41774p41814.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message