if you use a hi-res- or "retina-" screens whose device pixel ratio (dpr)* is higher than 1,
which is the case on all mobile devices and on most of all 13"-16" notebooks** nowadays,
you can notice that all thumbnails look blurry somehow.

*( developer.mozilla.org/en-US/docs/Web/API...dow/devicePixelRatio )

**(e.g. a windows notebook where the dislay scaling is set to "125% recommended" by default results in a dpr of 1.25 within the browsers viewport)

some developers / joomla gallery extensions make use of the 'srcset' attribute of the img HTML element:
developer.mozilla.org/en-US/docs/Web/HTM...ment/img#attr-srcset
developer.mozilla.org/en-US/docs/Learn/H...ng/Responsive_images
but then you have to maintain (generate) a set of thumbnails (2, 3 or even 4) with a different resolutions for different dpr.

e.g. a developer wrote:
a 'cheap' solution is to maintain (generate) only 2 sets of thumbnails where the second set is doubled in resolution and then you can manage all dpr from 1.0 to 2.0 (but with the use of 'srcset' attribute) - like the quoted developer above...

------

my suggestion for modals:
an even 'cheaper' (and less complicated) solution is to use only thumbnails with the exact double resolution,
but let the html/css resoltuion stay on the value that is chosen in the modals backend.
this way / as a compromise the thumbnails look better on any displays with dpr from 1.0 to 2.0 but with the disadvantage of higher bandwidth consumption...

so maybe by an option checkbox in the modals backend you can choose to generally use this hi-(double)-res-thumbnails,
and when choosing in the modals setting a thumbnail width of e.g. 320px
then the generated thumbnail files are 'physically' 640 x 360px
but in the generated html/css is still used width="320" height="180" attributes

here an example result with dpr = 1.25 (windows notebook with 125% display scale setting)


here an example result with dpr = 1.50 (windows notebook with 150% display scale setting)


I think one clearly can see the blurry effect ?
(watch this screenshots with 100% scaling on a device with dpr = 1.0)

the same is of course with most mobile devices
here are the original urls

watch this urls on a device with dpr > 1.0

nice, this seems to work well 👍
you've gone the way with creating two sets of thumbnails -> normal/doubled in size ?

but now with this version v12.0.0-dev2525995
I can not open the single images in some article
please see here:

within the two articles "thumbnail test: normal" and "thumbnail test: "double res"-thumbnail" the modal does not open,
but the two relating big pictures are existent:

my syntax is
{modal image="images/dokumente/testbild-1920px.jpg"}{/modal}
{modal image="/images/dokumente/testbild-1920px_2.jpg"}{/modal}
and I know that this two articles worked some beta versions before ...

can not figure out why ... can you have a look into the generated sourcecode, please

not really important / just a notice:
another odd thing is with the first article
in seen in category view

in category view you see the intro text only
and in the intro text I use the syntax:
{modal gallery="../my_path_to_subdirectory" thumbnails="random" thumbnail-width="160"}{/modal}
so thumbnail width of 160px is wanted
the generated html is thenso the generated thumbnail is "some_picture_160x107.jpg" seems to be 160px as we wanted,
but the css-width is written to [width="161"]
taking a closer look shows that the generated thumbnail is in fact 161px in its native size, so I think you read out the (freshly) generated thumbnail and then adjust the css width correctly (?)

so why we get this 161px thumbnail instead of the wanted 160px,
is it just some kind of rounding calculation error ?

works now ...


yes I still have the issue,
but only with this 2 articles (what is strange):

your access data:

glad you found the problem 👍😉

-----------------------------

back to the topic: "high-res" thumbnails:
this works now quite well and as expected (thanks for realizing this wish),
as long as you keep the loaded jpg-file-dimension equal or exact the double of the css- width and -height,
the thumbnail looks 'sharp' under almost any device pixel ratio (dpr) conditions.

I did a lot of testing with this feature and I found that chromium based browsers (edge/chrome/opera) works different than Gecko-based browsers (firefox) [didn't test WebKit-based browsers like Safari],
when it comes to interpreting the 'srcset' attribute :
you use now the scrset parameters '1x' and '2x' like so:displays with dpr = 1.0 load the (small) jpg that is given with the '1x'
and displays with dpr = 2.0 load the bigger (double-res) jpg that is given with the '2x'
(the css width="320" height="245" has to stay any time / at any dpr on the same value (e.g. the modals global setting)),
so far so good,

now (with this '1x'/'2x' setup) when / at wich dpr will the browser switch over to the bigger jpg ?
- firefox switches to the bigger jpg at a dpr of 1.1 (in fact: evrything "greater than 1.0")
- chromium switches to the bigger jpg at a dpr of 1.5 or higher (the exact middle between '1x' and '2x')

so with the example (from the very first post) using the windows notebook where the dislay scaling is set to "125% recommended" by default (dpr = 1.25),
you see the thumbnail still 'blurry' with chromium but 'sharp' with firefox.

(TBH: I personally prefer the firefox behaviour)
so to make the browsers behaviour almost the same
you could replace the '2x' with '1.5x' within the generated html I think*
(all the rest of the html-code stays the same, and the bigger jpg-file is still the same as well with the exact doubled resolution of the original thumbnail)

in this case chromium switches to the high-res jpg at a dpr of 1.25 or higher (the exact middle between '1x' and '1.5x')
and our example windows notebook (with the very common dpr of 1.25) shows the same 'sharp' thumbnail with firefox and chromium browsers.

so as a last wish: 😇
do you think this is meaningful and possible (to set it fixed on '1.5x') ?
or even make the second 'x' value adjustable within the backend [1.1 .. 2.0] ?

________________________
*html-spec says:

I think you get it (somehow) wrong (?)the scrset '1x' / '1.5x' / '2x' values do not declare (or 'mark') to the browser what size a picture is,
but instead at what dpr (of the display) the browser may load the given picture...
you may even write
srcset="testbild_3123x2555.jpg 2x, testbild_320x245.jpg 1x"
or
srcset="testbild_3123x2555.jpg 1x, testbild_320x245.jpg 2x"
and both works without a hassle (not useful of course )
(the browser doesn't care how big or what content the jpg is)


nope,
as I wrote above:all stays the same:
there are still 2 jpg's only, where the bigger one is double-resolution than the original
with the 'scrset' you only tell the browser at wich display-dpr to load which (of the two) pictures,
= at wich display-dpr to "switch over",
(and in fact the browsers switch over not at a dpr of 2.0 -> but much earlier at 1.1 (firefox) or 1.5 (chrome) already as I explained in my post above)


no,
I don't wanted to have a list,
I just wanted to make only the second value (only globally) selectable (or fixed to 1.5),
so there are still only two scrset values in the html of with the first one is '1x' always ...

you can check it with the browser-internal zoom-function,
just make two pics with different content (or one green and one red) and watch what happens when turning the browsers zoom-level up or down a lot -> when the picture will be switched over and so on ...
try this with '1x' and '2x' and then with an alternative '1x' and '1.5x' -scrset-configuration (but still the same jpg's),
try with chrome and firefox,
with the '1x' and '1.5x' -configuration chrome will switch over a little earlier. that's the only difference you will recognize


see here for example:
www.dev-diaries.com/social-posts/respons...images-with-src-set/
css-tricks.com/a-guide-to-the-responsive-images-syntax-in-html/
3rd link from my first post on this thread:
developer.mozilla.org/en-US/docs/Learn/H...ifferent_resolutions

__________________________________________

tbc: I don't expect you to realize this feature if you don't feel good with this,
this is just a small detail, that is not so important,
and should not delay you in any way from finishing the whole "modals for J4" project

newly introduced "Retina Pixel Density":
it works in backend settings as expected,
but it seems to me, that in frontend / in the generated html
always is put out '1.5x' no matter what I adjust in backend (?)



that works as well,
but it seems that you use all the full sized pictures to display the small pics within
<div data-modals-element="pagination">...</div> ?
(many kB to load then ? / or are they alredy loaded anyway with the first modal click cause it's a gallery)

another thing is the look and usability on mobile clients:
(no space anymore for the main picture)
you may check on your own mobile phone ...

I wrote:this issue is still the case with v12.0.0-dev2528689



you wrote:this works quite well now,
with a remaining 'blemish' only,
that in portrait* orientation on smaller screens or on mobile devices the whole modals window (with images pagination),
is on the very bottom of the screen (where perhaps one expected more that it would appear in the middle ?),
--> see picture
Or maybe you did it consciously ?
(just a matter of taste / personal preference then ...)

*(in landscape orientation it looks perfect)

yes,
I rectivated the access credentials
that I gave to you the last time (see above)

please try

just because I'm curious: what's the technical background that such kind of issues do not occur within your develeopment environment ?

now with v12.0.0-dev2529352:

# "Retina Pixel Density":
works now fine (and as expected) with the different browsers 👍

----------------

# "pagination using images for galleries":

## this type of pagination seems to work for galleries only and not for grouped images in an article
(in this case you will just see the 'dots' again)

## sometimes there is an unwanted vertical scrollbar attached on the right side of the modals picture
-> see screenshot taken with chrome browser: