Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider removing RenderMode.mixed and RenderMode.raster #31

Closed
greensopinion opened this issue Feb 21, 2022 · 5 comments
Closed

consider removing RenderMode.mixed and RenderMode.raster #31

greensopinion opened this issue Feb 21, 2022 · 5 comments

Comments

@greensopinion
Copy link
Owner

I'd like to consider removing raster-based rendering since with recent performance improvements, it's not clear that it offers any benefit.

By removing support for raster-based rendering we will no longer require users to understand what it is and how to choose a RenderMode option, or to decide how much memory and disk space to allocate to image storage. We also stand to benefit by dropping significant complexity from the codebase.

RenderMode (raster,mixed) was created as a way to work around performance problems that caused jank in the UI, especially while zooming. Both of these modes render tiles to raster images, which are expensive to create, occupy a lot of memory, and require significant disk space for caching.

It is somewhat ironic that these render modes are intended to improve performance but require a lot more computation. What makes it even worse is that raster images must be rendered on the UI thread, leaving less time for rendering UI frames. In the case of mixed mode, apps must render both vectors and images, more than doubling the work required.

This is a proposal to remove RenderMode completely, so that tiles are only rendered one way. See branch flutter-vector-map-tiles/tree/vector-only for what it could look like.

I've opened this issue in case there is any feedback from the community. Do you use RenderMode mixed or raster? If so, why do you prefer that over vector mode? Any and all feedback is appreciated!

@blaugold
Copy link

This sounds like a good idea to me. Best to remove the feature early when not too many people depend on it.
I haven't used the raster and mixed RenderModes much, though, so I don't know if there are certain cases where they are beneficial.

@greensopinion
Copy link
Owner Author

One thing to consider is that once a tile is rendered to a raster image and cached to disk, future use of the tile might be faster. This could be useful for older/underpowered devices.

@ibrierley
Copy link

Firstly, great stuff on all the work.

One thing I did do previously to experiment with my old stuff iirc, was to render to a raster in an isolate, save to disk, and then use that when available from the main thread (so just passing a ready confirmation via the isolate port). However, every raster type solution felt like clutter in the end and never really liked hybrid solutions and interfered with getting pure vectors working optimally which I think is similar to this thread.

I feel like it would be nice to keep the labels, and feel like it "should" be feasible, but maybe not just yet. Had a quick glance at the code, so I'm adding a few thoughts to the performance thread, even if it's closed, rather than clutter here, just in case any of it is helpful to someone.

@greensopinion
Copy link
Owner Author

@ibrierley thanks for the feedback!

I'm not sure what you mean about "keep the labels", feel free to elaborate.

@ibrierley
Copy link

ibrierley commented Feb 26, 2022

Heya, apologies, yes that wasn't clear. That was meant to be part of the other performance thread so would have made more sense there, but I missed that in my cut/paste! I was using Labels to mean the text and TextPainter type code. So street labels and city labels. Basically I think I was trying to work out if code like _createTextPainter() is called every build/canvas draw, or whether it is just called once (per text/coord and then cached/reused and then just the render() method used only).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants