Show HN: Forma – An efficient vector-graphics renderer • Hacker News Board

Re: Show HN: Forma – An efficient vector-graphics renderer

#61

Post by cercatrova » Mon, Dec 19, 2022, 1:33 AM UTC

matlin wrote: post #2

I'm curious how this relates to Skia (the library that handles cross-platform rendering for Chrome and Flutter). Seems like this could be an alternative backend but also could serve as faster replacement?

Flutter is moving to using Impeller, which is the faster replacement you're talking about: https://github.com/flutter/engine/tree/main/impeller

Re: Show HN: Forma – An efficient vector-graphics renderer

#62

Post by seanw444 » Mon, Dec 19, 2022, 3:21 PM UTC

Self-Perfection wrote: post #57

seanw444 wrote: post #15

Earlier quoted context omitted.

Was this conversation about OsmAnd+ by chance? Because that could use something like this. Edit: glossed over the "browser" part. My bad.

Just five days ago OsmAnd 4.3 for Android with new faster rendering engine that uses OpenGL was released. https://osmand.net/blog/osmand-android-4-3-released/#new-fas...

No way! It is waaaay faster now. It was unbelievably unperformant before, but I just dealt with it because it was otherwise a pretty good map app, especially using OSM and no Google spyware.

Re: Show HN: Forma – An efficient vector-graphics renderer

#63

Post by seanw444 » Mon, Dec 19, 2022, 3:23 PM UTC

nine_k wrote: post #47

xxswagmasterxx wrote: post #41

Earlier quoted context omitted.

I wonder why their renderer is so slow. Organic Maps is super fast and smooth on my phone, though.

Is it rendering or the database access? I see no slowness in OSM+ rendering on Android once the data for an area is loaded, as you pan, zoom, etc. But the pause between opening a new location and having it rendered is quite noticeable.

It was the rendering. I had read up on the related issue tickets, and the answer was that the vector rendering was both not optimized, and not cached in any way.

Re: Show HN: Forma – An efficient vector-graphics renderer

#64

Post by yangvz » Sat, Dec 24, 2022, 3:47 AM UTC

tayistay wrote: post #51

dragostis wrote: post #40

Earlier quoted context omitted.

A pixel segment is a line segment that fits inside of a pixel's square box. It can start and end anywhere inside of this 1x1 square box and it has a 64bit compact representation.

Ok, and when you sort these pixel-contained segments, what's the ordering?

I believe this refers to the z-ordering of pixel segments from different paths in the same pixel.