[JEWEL-746] Load inline markdown images using Coil3

[obask]

It supports every image as an inline node

[obask]

currently there are 2 differences with a JCEF render: JCEF renders SVG as a giant image while we keep it small(I guess it just depends on a default size parameter), and the text in build|failing is not shown for some reason...

[rock3r]

They look like entirely different images... Are you sure it's the same image it's being displayed, and that it's loading correctly in the first case? That to me looks like a "broken image" placeholder (which also is way too big)

SVG files have an intrinsic size declared in their root node, and any renderer should adhere to that

[obask]

images I posted earlier are examples of how JCEF renders my "README.md" which this is how compose shows the same things:

README.md

[rock3r]

I see. I had misinterpreted the original message, sorry 🙏

The first image (the broken square) has a declared size of 800x800 px, encoded as width="800px" height="800px", which browsers seem to accept but maybe the Compose renderer doesn't like, and falls back to the viewBox size of 16x16. That would explain why it's larger on JCEF.

As for the latter, I think it's because the text for whatever reason just doesn't get rendered:

<g text-anchor="middle" font-family="DejaVu Sans,Verdana,Geneva,sans-serif" font-size="11">
    <use x="5.5" y="2" fill="#010101" fill-opacity=".3" href="#logo" />
    <use x="5.5" y="1" fill="#fff" href="#logo" />
  <text x="40.5" y="15" fill="#010101" fill-opacity=".3">build</text>
  <text x="40.5" y="14" fill="#fff">build</text>
  <text x="83.5" y="15" fill="#010101" fill-opacity=".3">passing</text>
  <text x="83.5" y="14" fill="#fff">passing</text>
</g>

Again, possibly some unsupported value in there that Skia ignores.

That's sort of weird since Skia can interpret image sizes with units, and render text — it does in Chrome! But maybe there is some setup that is missing, or Chrome does some magic stuff. Either way, these are either CMP or Skiko bugs :)

[obask]

This fixes both:

• Load images in Markdown jewel#472
• Add support for inline images in Markdown jewel#746

[obask]

The first image (the broken square) has a declared size of 800x800 px, encoded as width="800px" height="800px", which browsers seem to accept but maybe the Compose renderer doesn't like, and falls back to the viewBox size of 16x16. That would explain why it's larger on JCEF.

As for the latter, I think it's because the text for whatever reason just doesn't get rendered:

Again, possibly some unsupported value in there that Skia ignores.

I'm going to create a separate issue for SVG regressions. Should it go to youtrack?

[rock3r]

Should it go to youtrack?

Please, no. Stick with GH until further notice. You'll know together with everyone else when YT is usable. We're still waiting.

[rock3r]

Does this belong here? It feels like it's init code, so having it once only (e.g., in ProvideMarkdownStyling?) would make more sense to me

[obask]

ProvideMarkdownStyling is in a different module and it's not guaranteed that a user will wrap Markdown into a style provider, so it may be confusing for debugging.
Will it attempt to invoke this code on each rerender or on each markdown usage in the app? I don't mind moving it somewhere, I just haven't figured out how exactly.

[rock3r]

Will it attempt to invoke this code on each rerender or on each markdown usage in the app?

It won't attempt to invoke, it will invoke it. That's why I'm saying it'd make more sense to do it elsewhere. I think we should even consider not using a singleton factory since users may want to use different ones; can we create one that we store in a composition local, and set it up in ProvideMarkdownStyling?

We can instruct users to use ProvideMarkdownStyling in the error message for when the composition local is not set up, like we do for other mandatory composition locals.

[obask]

In the message, I assume you're referring to invocation on each markdown usage?

The code itself is checking if an image loader already set before using compareAndSet to invoke a factory. I've set a debugger to see what's going on there. I assume one defererence on each markdown frame is not bad and I still don't completely follow the ProvideMarkdownStyling approach.

Does this sound reasonable or should I move this call out?

[rock3r]

I assume one defererence on each markdown frame is not bad

Yeah, that's ok, thanks for clarifying. But it's not my main concern. What happens if this is used in a context where the user has set their own loader? Seems to me like setting up a singleton image loader sets some expectations on our part that could be broken if the user had already done the same, with a different loader.

It also feels like we're leaking the loader outside Jewel, which is not very good either. We might be causing problems for our users because they expect to be able to set their own singleton IL, and it doesn't do anything if any Markdown composable just happened to be composed before then.

Is there no way to use composition locals to have a Jewel-only image loader that does not leak externally, and that we know we can trust? Of course, users can override it, but it's fine if they do it knowingly. It's the magical, undocumented side effect that is not acceptable.

[rock3r]

Out of curiosity, have you filed the issues for SVG rendering?

I think the size one is caused by https://github.com/coil-kt/coil/blob/main/coil-svg/src/commonMain/kotlin/coil3/svg/SvgDecoder.kt#L39 this parameter being true by default. Ideally, users should be able to override the Coil loader with one they want, but we can keep it for a follow up (it'd be nice to have an issue tracking this in our YouTrack, if you can file it).

The text one is the more baffling one. If you can look into it, maybe you can figure out what is the cause, or at least where it should happen, and file an issue for that in the right place.

[rock3r]

@obask ping

[obask]

Out of curiosity, have you filed the issues for SVG rendering?

Thanks for doing initial investigation. I filed a tracking issue, but not the one in a coil repository yet.
https://youtrack.jetbrains.com/issue/JEWEL-762/Coil-image-rendering-issues-with-SVG