Mailing Lists

Monday, 3 January 2022

Re: Wix site images

On 4 Jan 2022, at 3:18, Rob Kendrick wrote:

This is true, but it's not the reason websites do this. They do this
because it drastrically reduces their bandwidth costs and bursts of
activity on the httpd, which is important if you're paying AWS's rates.

Oh, for sure, I'm well aware that this kind of nonsense is done to favour the corporations and not the end users.

--   TTFN, Andrew Hodgkinson  Find photos, software, music and more at my home site, Bandcamp and GitHub:  https://pond.org.uk / https://pondnz.bandcamp.com / https://github.com/pond

On Mon, Jan 03, 2022 at 09:28:46AM +1300, Andrew Hodgkinson wrote:
> There is almost no universe in which this is better or faster than
> just letting the web browser load the original image directly, with
> the web site building providing a precise at-in-page-resolution copy
> of the image for the page and optionally a click-through to the full
> resolution version, if available and if permitted by the person who
> put the web site together.

This is true, but it's not the reason websites do this. They do this
because it drastrically reduces their bandwidth costs and bursts of
activity on the httpd, which is important if you're paying AWS's rates.

B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Sunday, 2 January 2022

Re: Wix site images

On 2 Jan 2022 as I do recall,
Andrew Hodgkinson wrote:

> On 3 Jan 2022, at 6:44, Harriet Bazley wrote:
>
> > How are these images supposed to work?
> >
> > [https://www.phantomlibrary.com/macabre-mystery-curse-of-the-nightingal](https://www.phantomlibrary.com/macabre-mystery-curse-of-the-nightingal)

[snip]

> They built a very over-complicated JavaScript system, that uses a custom
> element wrapping a standard IMG tag in the hope that a browser will
> ignore the outer custom element but render whatever it wraps. So, the
> browser renders the standard `img` tag, which contains a low resolution
> blurred preview of the actual image. JavaScript code looks for the
> custom `wix-image` elements and parses parameters in the various `data`
> attributes to work out how it's supposed to load and show the full
> resolution image to the user.
>

Thanks. At least in this case there is a way in which one *can* view
the missing images via some source-diving if they appear to be relevant
to the body text - more and more sites on the Web seem to be showing up
with their photos missing, presumably due to similar just-in-time JS
loading techniques.

--
Harriet Bazley == Loyaulte me lie ==

I like work; it fascinates me; I can sit and look at it for hours.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Wix site images

On 3 Jan 2022, at 6:44, Harriet Bazley wrote:

How are these images supposed to work?

https://www.phantomlibrary.com/macabre-mystery-curse-of-the-nightingal

First rule of the web: There's nothing you can't ruin with JavaScript.

Apparently, after loading 100s of K of JavaScript source code (at least it's < 1MB, small mercies!) that runs in your web browser using up your computer's resources, those smart developers at Wix realised - IDK - that the big thing causing slow loading times is images, because Reasons, maybe? Or they just wanted fancy loading transitions and hadn't heard of CSS. Whatever.

They built a very over-complicated JavaScript system, that uses a custom element wrapping a standard IMG tag in the hope that a browser will ignore the outer custom element but render whatever it wraps. So, the browser renders the standard img tag, which contains a low resolution blurred preview of the actual image. JavaScript code looks for the custom wix-image elements and parses parameters in the various data attributes to work out how it's supposed to load and show the full resolution image to the user.

One of the delightful side-quests is implementation of the "feature" wherein an image doesn't load until I scroll down to wherever it is showing on the page. I get to experience the joy of waiting for images to load over and over again, rather than the browser just loading them all when it fetches the page so that I can get on with viewing it without further delays or interruptions.

There is almost no universe in which this is better or faster than just letting the web browser load the original image directly, with the web site building providing a precise at-in-page-resolution copy of the image for the page and optionally a click-through to the full resolution version, if available and if permitted by the person who put the web site together.

--   TTFN, Andrew Hodgkinson  Find photos, software, music and more at my home site, Bandcamp and GitHub:  https://pond.org.uk / https://pondnz.bandcamp.com / https://github.com/pond

Wix site images

How are these images supposed to work?
https://www.phantomlibrary.com/macabre-mystery-curse-of-the-nightingal

<wix-image id="img_comp-kwl9a6lh" class="_1-6YJ _1Fe8-"
data-image-info="{"containerId":"comp-kwl9a6lh","displayMode":"fill","imageData":{"width":1022,"height":766,"uri":"9da2c5_b840c835b6f74327b9b75907f3e33c0d~mv2.png","name":"mm1.png","displayMode":"fill"}}"
data-bg-effect-name="" data-is-svg="false" data-is-svg-mask="false"
data-image-zoomed="" data-has-ssr-src="true"><img
src="https://static.wixstatic.com/media/9da2c5_b840c835b6f74327b9b75907f3e33c0d~mv2.png/v1/fill/w_180,h_135,al_c,usm_0.66_1.00_0.01,blur_2,enc_auto/mm1.png"
alt="mm1.png"
style="width:600px;height:449px;object-fit:cover;object-position:50%
50%"/></wix-image>

The *actual* intended picture can be accessed at
https://static.wixstatic.com/media/9da2c5_b840c835b6f74327b9b75907f3e33c0d~mv2.png
although since they seem to be over a megabyte each, I suppose one
should perhaps be grateful that the page isn't loading all seventy-odd
of them....

--
Harriet Bazley == Loyaulte me lie ==

Joseph Stalin's grave was a Communist Plot.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

[gccsdk] GCC 4.7.4 Rel 6: Wrong --version

Using --version with the utilities in !GCC.bin reports Release 5, rather
than Release 6.

Regards
Duncan Moore

gcc (GCCSDK GCC 4.7.4 Release 6) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISC OS 4.39
RPCEmu 0.9.3 RISC OS 5.24

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] GCC 4.7.4 Rel 6: SO Manager memory leak

The following programs cause the 'SO Manager' dynamic area to increase
to 1MB, and then fail with an error.
This happens on both VRPC and RPCEmu.

*Type c.true
int main(void) {return 0;}

*gcc -static -std=gnu11 true.c -o true

*Type c.err_SOM
#include <stdio.h>
#include <stdlib.h>
int main(void) {
for (int i=0;;++i) {
if ((i&0x7F)==0) printf("%i\n",i);
if (system("true")!=0) return 1; // Failure.
}
return 0;
}

*gcc -static -std=gnu11 err_SOM.c -o err_SOM

*err_SOM
0
128
256
384
512
640
768
There is not enough memory to perform this operation.
Quit any unwanted applications or see the RISC OS User Guide for ways to
maximise memory.
(Memory cannot be moved)

After this, any ELF commands give the same error message.

Regards
Duncan Moore

gcc (GCCSDK GCC 4.7.4 Release 6) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISC OS 4.39
RPCEmu 0.9.3 RISC OS 5.24

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK