2 GB Memory limitation

[Roni Keller]

Hi all,

We are using Skia to produce data for large industrial printers in real-time.
Since M98 surfaces seems to be limited to 2 GB. This highly restricts our printable area especially on high DPI inkjets.

Is this limitation only temporally (e.g., until some internal architecture is adapted)?
Are there any plans to remove this restriction in the feature?

Thanks for any inputs!
Roni

[Brian Osman]

Hi,

We had planned to leave that restriction in place, but I'm looking at the code again, and I think there is an easy way to relax it. However, we'd still only support surfaces up to 4GB (without significantly more work). There is also likely to be some performance impact on newer Intel CPUs to restore the 4GB capability. Is doubling surface size compelling, or are you interested in sizes even larger than that?

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/b5f26d89-1710-49bb-b961-6f2a21247aa2n%40googlegroups.com.

[Roni Keller]

Thank you a lot for the fast response. This is very appreciated!

If the effort is reasonable this would help us a lot for the time being. For the more distant future we would have to find a better approach (like splitting very large layouts into multiple Skia surfaces).

However, you mentioned that this may impact the performance on some CPUs. If this would affect all users of Skia (also with smaller surfaces) and not only us, it may not be worth it...

Regards

Roni

[Brian Osman]

Yes, the change I'm picturing would impact all users, so probably isn't worth it to us. Some kind of tiling solution is probably the best approach in the long run. Note that if you only need the surface to be very large (vs. source images), you may be able to do some trickery (this is untested and theoretical):

• Allocate your own pixel data for whatever size "surface" you want.
• Make a set of SkSurface objects that point into that block, at different sub-rectangles, using SkSurface::MakeRasterDirect.
• Create an SkNWayCanvas (include/utils/SkNWayCanvas), and add each surface's canvas to it. (I think you'd need to pre-translate each surface's canvas to match the offset within the large "surface").
• Do your drawing via the n-way canvas...

If you're using your own output code to serialize the final results, that may be sufficient. If you also use Skia's PNG encoder, I *think* you can invoke it directly by wrapping the giant meta-surface in an SkPixmap, and you won't encounter any of the surface/image restrictions.

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/c2ce16e1-7f96-4035-9c99-4fef46854a5cn%40googlegroups.com.

[Roni Keller]

Thank you for your very detailed description of the work around!
Using SkNWayCanvas works perfectly for our use case. In a first test I was able to render layouts that consumed over 5 GB memory without any issues.

With this solution in place, we have no more need to remove the 2 GB surface limitation.