[Isomorphic]

A quick update - it occurred to us that, probably in conjunction with a lack of caching, an issue with flickering might arise from there being ~1000 symbols in the sprite - symbols are shadow DOM elements, so vast numbers of them would take time for the browser to process. But we tested showing symbols directly from solid.svg (once mapped to currentColor) in a local Showcase and we still see no flickering.

If you only saw the flickering when using .svgIcon (ie, when setting SVG fill directly, rather than CSS color), there's a vague possibility that using CSS to set SVG attributes directly, rather than just CSS color, might behave differently enough that it can cause a flicker - we don't see that in testing or in the Showcase samples, though, so it seems unlikely.

In the meantime - we've added a new class, .icon, which sets CSS color, rather than SVG fill and stroke - you should see that in tomorrow's builds, dated March 30 and later.

[EDIT]

Note that, on further testing, we find that if your setup is not configured to cache SVG, then a sprite with hundreds of symbols may indeed cause flickering when applying stateful modifications to individual symbols, as a result of the browser re-loading and processing the entire sprite.

The solution is to ensure that image/svg+xml is cacheable.

[claudiobosticco]

Hello, thank you very much for your detailed explanations, much appreciated.

I can confirm that after enabling the caching via FileDownload servlet the flickering is gone.

About caching I must say that I've tried to use a webjar to pack the sprites files, but in this way I can't map the URLs in the FileDownload servlet, I mean, if I add:

   
    <servlet-mapping>
        <servlet-name>FileDownload</servlet-name>
        <url-pattern>/webjars/FontAwesome/*</url-pattern>
    </servlet-mapping>

then I get a 404. Is it not supported by the FileDownload servlet?

[Isomorphic]

We've never used WebJars. The FileDownload servlet will discover static files on either the filesystem or discoverable via the classpath (ClassLoader.getResource()).

From a conversation with ChatGPT, it looks like we are meant to translate "/webjars" to "META-INF/resources/webjars". We can add that.

[claudiobosticco]

In the meantime - we've added a new class, .icon, which sets CSS color, rather than SVG fill and stroke - you should see that in tomorrow's builds, dated March 30 and later.

SmartClient Version: SNAPSHOT_v13.1d_2024-03-30/AllModules Development Only (built 2024-03-30)

I can confirm it's working with fontawesome svg sprites after adding fill="currentColor", thank you very much

[claudiobosticco]

We've never used WebJars. The FileDownload servlet will discover static files on either the filesystem or discoverable via the classpath (ClassLoader.getResource()).

From a conversation with ChatGPT, it looks like we are meant to translate "/webjars" to "META-INF/resources/webjars". We can add that.

Hello, will you please update this thread if you'll add the translation for webjars? TIA

[claudiobosticco]

SNAPSHOT_v13.1d_2024-05-14/Enterprise Deployment

Hello, I've just noticed that with the latest builds, in my ToolStripButton where I'm using svg spriting, I get a '/images' added before the path of my svg file, is it an intended change?

[Isomorphic]

No, that's not an intentional change - we'll take a look. Are you using path shortcuts like [SKIN] or [SKINIMG] in your src strings?

[claudiobosticco]

No, that's not an intentional change - we'll take a look. Are you using path shortcuts like [SKIN] or [SKINIMG] in your src strings?

nope, just the path of my webjar

[claudiobosticco]

Hi, were you able to reproduce the problem?
It occurs for me when using a relative path, ie "images/solid.svg". It doesn't happen with an absolute path. Essentially, when the Button is created, the icon URL is correct, but on hover, "/images" is added to the path. I would say it happens with every type of Button.

[Isomorphic]

Apologies, this one slipped a bit - we'll punt it up the list and take a look today

[Isomorphic]

hi Claudio,

An additional "images" here likely implies an errant call to Page.getImgURL(), but some simple testing inhouse doesn't show an issue.

Can you show a brief sample that has the problem? You can use a builtin SVG in your test code - set your button.icon to "sprite:svg:[HELPERS]media/svg/chevrons.svg#arrow_right", or just it's direct stockIcon name "Chevron_Right" - either will work.

[Isomorphic]

Actually, never mind - we see the issue when the path is relative. We'll put a fix in today.

[Isomorphic]

Ok, this is fixed for tomorrow's builds, dated May 31 and later.

When the chevrons.svg sprite is local to your page, this code below will now show the proper icon, and the proper state, on mouseOver/mouseOut.

isc.ToolStripButton.create({
    ID: "alignRight",
    showRollOverIcon: true,
    icon: "sprite:svg:chevrons.svg#arrow_right;cssClass:icon;"
});

[claudiobosticco]

I can confirm it's fixed, thank you very much

[claudiobosticco]

Hello, I don't know if it's related to the above fix, but now I see png icons in the showcase which disappear on hovering, ie the tabs icons here https://www-demos.smartclient.com/sm...izeIncrease=10