Federico Mena Quintero is a user on mastodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

@federicomena If I only had the time, improving Cairo would be something that I would definitely like to get into. In particular it completely riles me up is the limitation of surface size to 32768px, this has bitten us many times in WebKit, and it's only going to get worse now with HiDPI displays.

@federicomena I am aware that fixing the surface maximum size would be getting into quite a lot of churn, and potentially introducing ABI/API incompatibilities (haven't looked much into this one bit), but it would still be a very worthy goal. Because 32768px ain't enough for some tasks.

@aperezdc Hmmm, I'm starting to deal with fixed point overflows, which is not directly tied to the max surface size, but I am curious about it. Tell me more? When is that size not enough?

@federicomena For example when some websites will serve sprite sheets e.g. all emojis as a single PNG, which may be one column or row of sprites (so 32x35000px, or 35000x32px)

@federicomena A less borderline case than image sprite sheets is taking a “screenshot” of all the contents of a webpage (not just what's seen on the window): when the page is a few (15-20) screenfulls, like a long Wikipedia article, which can easily be more than 32K px tall. Or for shorter pages around 16K px tall, if a 2x scale factor is in use (because HiDPI), there you go again over the 32K size limit.

@federicomena I could probably find more examples, but those two are just from the top of my head without even needing to go and dig bug reports.

For example, this bug took months to “fix” because Hangouts/GMail used a PNG as sprite sheet with a height of 33K px and we were blinded by the possibility that the accelerated compositing code would be to blame (which would be more likely), and it wouldn't be reproducible for everybody because some people wouldn't get the huge sprite sheet → bugs.webkit.org/show_bug.cgi?i

(Note: the “fix” was to just disable rendering of huge images, so it is actually a workaround 😥 )

@federicomena

the version in Guix is 1.14.10 but the most recent version I see on your Gitlab branch is 1.12.14

am I wrong ?

@catonano the most recent tag is 1.12.14; I didn't push all the tags to the gitlab repository. The code is up to date with Cairo's git master.

@federicomena

I cloned it and attempted to run autogen.sh on GuixSD

The resut follows. Is it any good ? Or can you spot any incompatibility ?

paste.freshbakedyams.com/paste

@federicomena

interestinlgy, I get

492 Passed, 59 Failed [0 crashed, 14 expected], 27 Skipped

it's 5 more failures than you get

here:
paste.freshbakedyams.com/paste

the interesting bit is on line 600 and 601

clip-operator fails. But I can't find clip-operator.log

am I missing anything ?

@catonano Ah! I've already regenerated that test file. Try this branch? gitlab.com/federicomenaquinter

It's where I'm seeing if test files just need to be regenerated, or if there are actual bugs to be fixed.

@federicomena

for example, extended_blend_mask fails but I can't find a

extended_blend_mask.log

Is this expected ?

@catonano I'm debugging extended-blend-mask right now. Glad that you discovered test/output/* :) Need to review test/README to see if it actually mentions that.