On Wed, 21 Oct 2026 02:32:08 GMT, John Hendrikx <[email protected]> wrote:
>> 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). another scenario is an attempt to `fillRect` with coordinates that overflow, such as (-50000, 0, 50001, 1). in theory, this should fill its pixel. This is pre-existing, and a bit contrived - I don't know whether we should even address it (although I do like your idea of using wider numbers in computations prior to rendering) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1969#discussion_r4362004539
