On Tue, 20 Oct 2026 23:44:19 GMT, John Hendrikx <[email protected]> wrote:
>> I recall `Canvas` failing with smaller dimensions due to failed allocation, >> but I don't have the record. Even more, the `Canvas` is intended to be >> displayed on screen, so we don't expect it to be too large, right? >> >> With the DC API, we might actually expect users creating giant contexts. >> Should we explicitly mention the size limit in the constructor? > > Canvas indeed also has problems when you exceed the texture size of the GPU, > so you can't make a 100k x 1 Canvas. The problem there is that it isn't as > easily solved with tiling as drawing operations that cross textures are hard > to get right. Images have no such problems as the operations always happen on > a single chunk of memory, and tiling only happens afterwards. > > As for a size limit, I suppose we can mention it as a known limitation, but > it is one that can be removed with more work (unlike a tiled Canvas, which is > a much harder problem), so it shouldn't be part of the specification. I've added general wording to `DrawingContext` that the maximum size is up to the implementation; then I added docs to the methods where you obtain a `DrawingContext` or `GraphicsContext` (I kept the latter very concise as it is complicated). For `getDrawingContext` the limitation for now is no more than 32767 pixels; this is for now a hard limitation as Pisces uses fixed point math (16 bits for the integer part, 16 bits for the factional parts ... reminds me of the old days before floating point was commonly available on CPU's) For `GraphicsContext` it is a lot more complicated, the maximum size depends on: - The display scale (texture size is increase by a factor of display scale rounded up to the next integer) -- so on a 1.5 display, it uses a texture twice as large, meaning you run into the maximum size limit earlier - Whether the SW or HW pipeline is in use - SW uses Pisces which has the same limits as our new implementation, but if texture size was increased, that limit is further reduced here as well - HW relies on texture size limits, which depends on the GPU/driver/OS etc... Tiling unfortunately does not save the SW implementation here (using a PixelWriter does allow you to use huge images, but obtaining the DrawingContext will throw). It may be possible to adjust Pisces to use a different trade-off (fixed point math 24.8 instead of 16.16) or to make it use 64-bit integers (on modern CPU's that shouldn't matter performance wise). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1969#discussion_r4332427843
