|
HCrikki
|
2023-10-16 11:34:13
|
*AntiDupl.NET* added support for jxl in 2.3.12 (final build, marked prerelease on github). Its a scanner/cleaner for duplicate images https://github.com/ermig1979/AntiDupl
|
|
|
Oleksii Matiash
|
|
Here's the dump from exiftool, spent 20 minutes trying to just extract all preview files but nothing would happen, after comparing to a downloaded file it looks like there's no preview section near the bottom
|
|
2023-10-17 05:54:09
|
|
|
2023-10-17 05:55:15
|
Explorer icons (previews) are shown immediately
|
|
|
jonnyawsom3
|
2023-10-17 05:57:05
|
Interesting, I guess it uses embedded previews if available and decodes the actual data as fallback
|
|
|
username
|
2023-10-17 05:58:09
|
here's what I believe is happening, Windows has a codec for decoding full DNG files (not previews) **however** the UWP Windows Photos app is not allowed to use it but file explorer is so the photos app just uses the generated preview from file explorer decoding the DNG
|
|
2023-10-17 05:58:31
|
I bet if you used the classic Windows Photo Viewer program it would display the full DNG
|
|
|
Interesting, I guess it uses embedded previews if available and decodes the actual data as fallback
|
|
2023-10-17 05:59:02
|
typed out all my messages before reading this so uh I don't know what's happening here but it could be some weird back and forth between explorer and the photos app
|
|
|
|
jonnyawsom3
|
2023-10-17 06:01:55
|
There definitely is some form of caching, but file explorer and the Photos app aren't sharing. Even with the file explorer thumbnails generated (Sometimes after a dozen seconds each), the Photos app still takes a few seconds of loading before displaying, then is instant after the first time
|
|
|
Interesting, I guess it uses embedded previews if available and decodes the actual data as fallback
|
|
2023-10-17 06:03:32
|
Actually, here's the file <@1102876331986927627>. You can see how the loading compares to your DNGs
|
|
|
|
Oleksii Matiash
|
|
Actually, here's the file <@1102876331986927627>. You can see how the loading compares to your DNGs
|
|
2023-10-17 06:06:22
|
Immediately. Don't mind colors, my monitor is wide gamut one
|
|
|
|
jonnyawsom3
|
2023-10-17 06:08:04
|
Interesting, then again I am on a first gen Ryzen CPU too. Is it roughly what you expected or does it not seem like a preview/thumbnail to you?
|
|
|
|
Oleksii Matiash
|
|
Interesting, then again I am on a first gen Ryzen CPU too. Is it roughly what you expected or does it not seem like a preview/thumbnail to you?
|
|
2023-10-17 06:22:52
|
I'm on 7950x, but it does not even try to work while displaying dngs. I looked inside your dng, and it seems to me that it does not have any previews at all. So looks like Win11 Photos is showing real raw data, if there is no thumbnail, i.e. performs honest demosaic, etc. I don't know how it could be so fast, but maybe it is clever enough to do it using GPU? It could explain the speed, because I have 4080, and Adobe Raw Convertor also shows such small raws immediately and without any visible CPU usage.
|
|
|
|
jonnyawsom3
|
2023-10-17 06:30:34
|
First DNG I opened only used 2% CPU for a second or two, not sure what's happening on the second DNG, but it had no file explorer thumbnail either, very strange...
|
|
|
Foxtrot
|
2023-10-21 03:29:37
|
test rendering of JXL merged to WPT https://github.com/web-platform-tests/wpt/pull/42626
|
|
|
Quackdoc
|
|
Demiurge
|
2023-10-21 09:01:49
|
https://docs.krita.org/en/general_concepts/file_formats/file_jxl.html
|
|
2023-10-21 09:02:40
|
Looks like some limitations with layers? Is this an API problem or a krita implementation problem?
|
|
|
|
jonnyawsom3
|
2023-10-21 09:25:52
|
> Squirrel – Enables dots, patches and **spline detection** as well as context clustering.
Something makes me doubt that
|
|
|
|
Demiurge
|
2023-10-22 01:11:22
|
That's what the libjxl documentation says. But it's wrong. But it's based on what it says
|
|
|
Yaywalter
|
2023-10-22 04:33:12
|
My search for an iPad comic viewer app that supports archives containing JPEG-XL has finally come to a close... Booklover. it's a paid app, though fortunately only a one-time $4 purchase... and it seems well made enough to be worth it beyond just the JXL support.
|
|
|
|
Demiurge
|
2023-10-23 07:32:51
|
CB7 with JPEG probably compresses better than JPEG XL, more redundancy for LZMA to take advantage of in my experience
|
|
|
|
Quackdoc
|
2023-10-23 07:42:25
|
introducing a revolutionary new comic book format.
.mkv.gz
|
|
|
|
Yaywalter
|
2023-10-23 09:34:26
|
Testing it out, an 83.1 MB JPEG-format comic reduces to 80.9 when archived as 7z (81.1 for zip). Losslessly converting the comic to JXL reduces it to 70.7, though doesn't go any lower when archived as 7z/zip.
|
|
|
Jabster28
|
|
Demiurge
CB7 with JPEG probably compresses better than JPEG XL, more redundancy for LZMA to take advantage of in my experience
|
|
2023-10-23 10:07:42
|
thats typically true, but jxl knows that it's dealing with images, and thus it can make certain decisions that lead to smaller sizes than 7z
|
|
|
|
Demiurge
|
|
Yaywalter
Testing it out, an 83.1 MB JPEG-format comic reduces to 80.9 when archived as 7z (81.1 for zip). Losslessly converting the comic to JXL reduces it to 70.7, though doesn't go any lower when archived as 7z/zip.
|
|
2023-10-23 10:20:28
|
Interesting! So JXL still can win. I guess there has to be a lot of cross image redundancy for JPEG to be better
|
|
|
|
jonnyawsom3
|
2023-10-24 12:47:11
|
Don't think this has been mentioned before, has a JXL converter (Although lacking many settings) and seems to have a lot of articles on jpeg and PNG compression and how best to optimize them https://compress-or-die.com/
|
|
|
|
Demiurge
|
2023-10-24 03:22:35
|
How about JXL lossless jpeg compression?
|
|
|
|
JendaLinda
|
2023-10-24 09:11:38
|
JXL is much better at compressing large blank (solid color) areas in images. In JPEG and PNG these will result in long strings of repeating bytes.
|
|
2023-10-24 09:13:15
|
So if you have lots of pictures with white border around, this will add up.
|
|
2023-10-24 09:29:40
|
This seems to be a limitation of older algorithms that can compress only limited amount of bytes to single byte.
|
|
|
VcSaJen
|
|
Jabster28
thats typically true, but jxl knows that it's dealing with images, and thus it can make certain decisions that lead to smaller sizes than 7z
|
|
2023-10-24 12:11:19
|
RAR used to have format-specific compressions, but that was removed in modern versions.
|
|
|
|
Demiurge
|
2023-10-26 07:14:42
|
A lossy format that meets everyone's expectations is very rare. Maybe pngquant
|
|
2023-10-26 07:15:09
|
Pngquant is really good in my experience
|
|
2023-10-26 07:15:52
|
Would be nice if it was merged into libjxl
|
|
2023-10-26 07:16:10
|
libjxlquant
|
|
|
|
JendaLinda
|
2023-10-26 09:20:10
|
Pngquant is juts a fancy converter from true color to indexed color, reducing the number of unique colors to 256, so the image will fit the paletted PNG format.
cjxl already allows lossy palette mode, reducing the number of colors, although JXL can use palettes much bigger than just 256 colors.
|
|
|
|
jonnyawsom3
|
2023-10-26 09:22:06
|
Yeah, if I recall lossy uses quantization by default, which is why colors shift hue unless you lower the distance
|
|
|
|
JendaLinda
|
2023-10-26 09:34:39
|
But the PNG compression is not that smart so it benefits from some preprocessing. After all it was made for computers hundred times slower than today's computers. JXL uses much more advanced compression techniques so it can do better than PNG without losing quality.
|
|
|
lonjil
|
2023-10-26 09:41:50
|
JXL could probably make good use of something like WebP's near lossless pre-processing.
|
|
|
|
JendaLinda
|
2023-10-26 09:44:05
|
I t would be interesting how would it compare to high quality VarDCT.
|
|
|
|
jonnyawsom3
|
2023-10-26 09:45:56
|
Supposedly it already can, or at least https://squoosh.app/ has a "slight loss" option
|
|
|
Cacodemon345
|
2023-10-26 09:46:37
|
PNG's compression scheme is basically apply filter to the pixels and then ZIP them.
|
|
2023-10-26 09:47:38
|
And that's pretty much it.
|
|
|
_wb_
|
2023-10-26 09:48:26
|
there's an experimental encoder that uses delta palette, but my feeling is that we're only scratching the surface of the bitstream potential, and there's a lot of research and engineering that can still be done to make optimal use of all the coding tools that are available
|
|
2023-10-26 09:49:31
|
I mean, we're not even done with exploring all the potential of JPEG and PNG, and those have a pretty limited bitstream expressivity compared to JXL
|
|
|
|
JendaLinda
|
2023-10-26 09:55:16
|
Splines come to mind, for example, but there's no automated way to make use of them AFAIK.
|
|
|
|
jonnyawsom3
|
2023-10-26 10:02:58
|
I did have the passing dream of hardware accelerated spline detection, since normal heuristics are far too costly. Although it'd be immensely better if we can work smarter rather than harder
|
|
|
|
JendaLinda
|
2023-10-26 10:11:34
|
That's the thing, the compression must not be slow.
|
|
|
gb82
|
2023-10-29 04:46:07
|
Should we add Cromite to https://jpegxl.info/ ?
|
|
|
MSLP
|
2023-10-29 07:47:43
|
Btw. does anyone know something more about Midori browser? Is it safe to use? As I checked it's now gecko-engine based browser (pre-2023 it was WebKit based) and it has JXL support enabled by default; also it seems it has merged the patches for gecko JXL improved support, so animations and transparency are working correctly.
|
|
|
|
Quackdoc
|
2023-10-29 08:27:21
|
midori browser is kinda all over the place, don't really recommend it for now. IIRC rightnow they are re-writing a bunch of stiff to get the android and desktop to use a single code base (IE. using geckoview for android)
|
|
|
|
MSLP
|
2023-10-29 08:28:12
|
right, jxl support is not yet in android version
|
|
|
|
username
|
2023-10-29 08:39:59
|
Midori's JXL support is inherited from Floorp since the new gecko version of Midori uses Floorp as a base
|
|
2023-10-30 12:55:00
|
the Wikipedia page is outdated and missing the recent information of Midori starting fresh using gecko/Firefox/Floorp as a base instead of WebKitGTK which means that it should support all the same extensions that modern Firefox does
|
|
2023-10-30 12:55:40
|
the new version of Midori based on Floorp had it's first release 2 days ago
|
|
|
|
Demiurge
|
2023-10-30 04:13:04
|
In theory. But in practice there isn't any jxl encoder that actually takes advantage of a lot of the techniques employed by other clever optimizers for other formats, like GIF optimizers.
|
|
2023-10-30 04:20:48
|
The jpegxl format has a lot of special abilities other formats don't have... But if the encoder doesn't even take advantage of things that are possible with the encoding tools for other formats, let alone things that are only possible with jpegxl, then it has no practical effect until someone writes some clever encoding tools that write jpegxl
|
|
2023-10-30 04:55:44
|
Currently libjxl is pretty good and pretty competitive with other lossy DCT encoders like JPEG and AVIF, but it is beaten by lossless webp and gif optimizers and doesn't take advantage of any clever near-lossless tricks/filters that are available for other formats and could probably benefit jpegxl too if someone tried to bring those techniques over
|
|
|
yoochan
|
2023-10-30 08:10:13
|
for the compression ratio, jpegxl is not beaten by wepb en average (even if it is it's closest match) https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit#gid=174429822
|
|
|
monad
|
2023-10-30 10:38:22
|
Depends on content and compute allowance. Last I checked, WebP was dominant in max compression of images with lots of repetition, like screenshots of text or tile-based games. If speed is a concern, WebP is good for limited palette stuff. Otherwise, it's the JXL party.
|
|
|
|
jonnyawsom3
|
2023-10-30 11:23:17
|
I've lost track of how many times it's been brought up, but the WebP palleted images beating JXL is most likely due to pallete ordering, which is going to be ported over to JXL in future
|
|
|
damian101
|
2023-10-31 03:10:20
|
Any image viewer for Linux that can display both AVIF and JPEG XL and is not Gwenview?
|
|
2023-10-31 03:10:52
|
Gwenview has been terribly bugged for me for a while now... always freezes
|
|
|
|
lonjil
|
2023-10-31 03:11:24
|
Any Qt-based image viewer if you have the appropriate image coding plugins installed. Which it sounds like you do.
|
|
|
|
damian101
|
2023-10-31 03:11:48
|
yes indeed...
|
|
2023-10-31 03:11:52
|
what others are there?
|
|
|
|
lonjil
|
2023-10-31 03:12:11
|
good question
|
|
|
|
damian101
|
2023-10-31 03:13:35
|
Phototonic works
|
|
2023-10-31 03:15:29
|
It confuses my X11 display scaled resolution with the native resolution...
|
|
2023-10-31 03:15:35
|
otherwise works fine
|
|
2023-10-31 03:20:27
|
seems like Gwenview bugs out when I open more than one instance... which I of course often do to compare image quality
|
|
|
spider-mario
|
|
Any image viewer for Linux that can display both AVIF and JPEG XL and is not Gwenview?
|
|
2023-10-31 03:37:15
|
potentially, libjxl’s “`compare_images`” could, if we converted the benchmark codec for AVIF into a `lib/extra/` codec
|
|
|
|
HCrikki
|
|
what others are there?
|
|
2023-10-31 03:49:26
|
gthumbs 3.12 and newer (flathub in particular, works on all distros)
|
|
2023-10-31 03:54:31
|
if you have a recent kde, any qt app app leveraging kimageformats 5.89 and newer should decode jxl and avif (KDE Frameworks 5.89 shipped in dec 2021)
|
|
2023-10-31 03:56:18
|
flathub should be preferred imo unless youre using a rolling release distro like arch that consistently ships the latest stable build of everything from upstream instead of freezing an old codestream and mess it with backported frankencode
|
|
2023-10-31 04:05:37
|
afaik Loupe (which replaced Eye of Gnome) also supports both jxl and avif now. flathub could be preferable as some distros might not be shipping a jxl decoder in some configurations (like ubuntu 23.10's 'minimal' install which got relabelled the normal install)
|
|
|
novomesk
|
|
what others are there?
|
|
2023-10-31 05:21:33
|
qView, PhotoQt, nomacs, digiKam
|
|
|
Eugene Vert
|
|
what others are there?
|
|
2023-10-31 06:22:34
|
qimgv, and it has very good support for video via mpv
|
|
2023-10-31 06:23:04
|
Also digiKam is great for image management
|
|
|
|
lonjil
|
2023-10-31 06:23:53
|
hm, I have qimgv and KDE's jxl support installed, but qimgv doesn't seem to support jxl
|
|
|
|
Eugene Vert
|
|
lonjil
hm, I have qimgv and KDE's jxl support installed, but qimgv doesn't seem to support jxl
|
|
2023-10-31 06:27:20
|
`kimageformats`, right? This's weird
|
|
|
|
HCrikki
|
2023-10-31 06:29:52
|
some distros ship kimageformat with jxl disabled
|
|
|
|
lonjil
|
|
Eugene Vert
`kimageformats`, right? This's weird
|
|
2023-10-31 06:30:41
|
yeah.
|
|
|
|
Eugene Vert
|
2023-10-31 06:30:52
|
KDE's jxl plugin is usually in `/usr/lib64/qt5/plugins/imageformats/kimg_jxl.so`, could it be a build without jxl indeed?
|
|
|
|
lonjil
|
|
HCrikki
some distros ship kimageformat with jxl disabled
|
|
2023-10-31 06:30:56
|
jxl is working in Gwenview and in Dolphin thumbnails
|
|
|
Eugene Vert
KDE's jxl plugin is usually in `/usr/lib64/qt5/plugins/imageformats/kimg_jxl.so`, could it be a build without jxl indeed?
|
|
2023-10-31 06:32:25
|
yep, it's there
|
|
|
|
Cacodemon345
|
|
HCrikki
some distros ship kimageformat with jxl disabled
|
|
2023-10-31 07:10:57
|
Now that's dickheaded.
|
|
|
|
MSLP
|
|
what others are there?
|
|
2023-10-31 07:11:32
|
also geeqie
|
|
|
|
VcSaJen
|
2023-11-01 01:07:44
|
Apparently "Vitis Libraries" from Xilinx hardware/software support JXL encoding:
https://docs.xilinx.com/r/en-US/Vitis_Libraries/codec/benchmark/jxlEnc.html
|
|
|
derberg
|
|
what others are there?
|
|
2023-11-01 01:08:17
|
feh and sxiv (and thus als nsxiv which somehow uses thrice as much RAM on my system) and inferior (aka. slow in directories with many pictures) mirage, gpicview and eog
|
|
|
|
gb82
|
|
Any image viewer for Linux that can display both AVIF and JPEG XL and is not Gwenview?
|
|
2023-11-02 07:13:54
|
loupe for GNOME
|
|
|
Fraetor
|
2023-11-02 08:58:07
|
Eye of GNOME also works if you have the gdk-pixbuf jxl library installed.
|
|
|
Traneptora
|
2023-11-03 10:06:14
|
I use Eye of MATE and can confirm
|
|
2023-11-03 10:06:39
|
note that EoG/EoM doesn't understand cICP
|
|
|
|
veluca
|
2023-11-03 11:17:20
|
they also don't support hdr anyway, so...
|
|
|
|
spider-mario
|
2023-11-03 11:29:57
|
and as far as we’ve been able to determine, the gdk-pixbuf plugin interface doesn’t support any sort of colour management
|
|
2023-11-03 11:30:04
|
it seems that sRGB is just assumed
|
|
2023-11-03 11:30:46
|
not sure if eog implements the common formats directly, to bypass gdk-pixbuf
|
|
|
|
damian101
|
|
veluca
they also don't support hdr anyway, so...
|
|
2023-11-04 11:37:16
|
it's important that the correct color matrix is used when decoding AVIF...
|
|
|
|
veluca
|
2023-11-04 11:41:45
|
I thought libavif undid the YUV stuff
|
|
|
|
damian101
|
|
veluca
I thought libavif undid the YUV stuff
|
|
2023-11-04 11:45:05
|
how do you mean
|
|
|
|
veluca
|
2023-11-04 11:45:49
|
The cicp color matrix / matrix coefficients specifies what kind of yuv transform was applied
|
|
|
|
damian101
|
|
|
veluca
|
2023-11-04 11:46:26
|
(must be 0 for PNG, for example, i.e. rgb / no transform)
|
|
2023-11-04 11:46:53
|
I'd expect libavif to apply that transformation before handing the pixel data over
|
|
2023-11-04 11:47:02
|
In fact I am fairly sure it can do that
|
|
|
|
damian101
|
2023-11-04 11:47:03
|
default is 5 for avif, BT.470 B/G
|
|
|
veluca
I'd expect libavif to apply that transformation before handing the pixel data over
|
|
2023-11-04 11:48:49
|
avifdec needs the matrix metadata to correctly decode the YUV content
|
|
|
|
veluca
|
2023-11-04 11:49:11
|
https://github.com/AOMediaCodec/libavif/blob/main/include/avif/avif.h#L791
|
|
2023-11-04 11:49:32
|
and the avif file contains that metadata
|
|
2023-11-04 11:49:35
|
I don't see the problem 🙂
|
|
|
|
damian101
|
|
veluca
and the avif file contains that metadata
|
|
2023-11-04 11:49:49
|
that's my point?
|
|
2023-11-04 11:49:57
|
if it's ignored, it decodes incorrectly
|
|
2023-11-04 11:50:09
|
oh
|
|
2023-11-04 11:50:16
|
I see your point
|
|
2023-11-04 11:50:55
|
yeah, if avifdec is used to convert to RGB already, there is no issue
|
|
|
|
veluca
|
2023-11-04 11:52:18
|
yup
|
|
2023-11-04 11:52:30
|
and presumably that's exactly what you want to do in something like eog
|
|
2023-11-04 11:52:45
|
which I'd assume doesn't have infra to hand YUV data to the GPU
|
|
|
|
damian101
|
2023-11-04 11:58:08
|
yes, it's just not usually done this way
|
|
2023-11-04 11:59:33
|
and it's not necessarily done this way for AVIF, it depends on the decoder
|
|
|
|
Traneptora
|
|
spider-mario
and as far as we’ve been able to determine, the gdk-pixbuf plugin interface doesn’t support any sort of colour management
|
|
2023-11-05 02:00:20
|
Eye of MATE at leasts supports ICC Profiles in PNG and JPG files
|
|
2023-11-05 02:00:29
|
it just doesn't understand cICP
|
|
2023-11-05 02:01:26
|
I think the ICC metadata is provided by the gdk-pixbuf decoder, but not the cICP metadata
|
|
2023-11-05 02:01:47
|
so it sees "untagged" and assumes sRGB
|
|
|
|
spider-mario
|
2023-11-05 02:02:10
|
we also support ICC profiles in JXL files in the gdk-pixbuf plugin, but we have no way to propagate it or know what the output space should be, so we just convert to sRGB
|
|
|
|
Traneptora
|
2023-11-05 02:02:28
|
that's interesting, I thought that metadata was propagated
|
|
|
spider-mario
we also support ICC profiles in JXL files in the gdk-pixbuf plugin, but we have no way to propagate it or know what the output space should be, so we just convert to sRGB
|
|
2023-11-05 02:05:19
|
https://docs.gtk.org/gdk-pixbuf/method.Pixbuf.set_option.html
|
|
2023-11-05 02:05:34
|
apparently you set "icc-profile" key, and the ICC profile is base64-encoded as a string as the value
|
|
|
|
spider-mario
|
2023-11-05 02:05:58
|
oh
|
|
2023-11-05 02:06:02
|
very discoverable
|
|
2023-11-05 02:06:09
|
thanks, that should be very useful
|
|
|
|
Traneptora
|
2023-11-05 02:06:12
|
I figured that out by reading *save*
|
|
2023-11-05 02:06:13
|
https://docs.gtk.org/gdk-pixbuf/method.Pixbuf.save.html
|
|
2023-11-05 02:06:41
|
so I'm extrapolating
|
|
|
|
spider-mario
|
2023-11-05 02:07:26
|
the main current source of slowness in the gdk-pixbuf jxl plugin is the conversion to sRGB
|
|
2023-11-05 02:07:43
|
if we don't actually have to do it, that solves the question
|
|
|
|
Traneptora
|
|
spider-mario
if we don't actually have to do it, that solves the question
|
|
2023-11-05 02:09:28
|
https://gitlab.gnome.org/GNOME/gimp/-/blob/master/libgimpcolor/gimppixbuf.c#L132
|
|
2023-11-05 02:09:31
|
here's how GIMP does it
|
|
2023-11-05 02:10:10
|
so it looks like setting that option in the loader should work correctly
|
|
|
|
veluca
|
2023-11-05 02:12:15
|
we should probably do that
|
|
2023-11-05 02:12:57
|
once I'm back from vacation & the cms stuff is in, I think
|
|
|
|
Traneptora
|
|
veluca
we should probably do that
|
|
2023-11-05 07:22:16
|
I can take a look at sending a PR tonight
|
|
|
|
damian101
|
2023-11-06 03:37:04
|
btw, I decided to go with qimgv
|
|
2023-11-06 03:37:25
|
surpsingly, many of the others took very long to open and display the image...
|
|
2023-11-06 03:38:27
|
tried all recommended and uninstalled all again except for nomacs and qimgv
|
|
|
|
MSLP
|
|
btw, I decided to go with qimgv
|
|
2023-11-06 04:20:35
|
it seems qimgv also supports videos. Pinging <@958646019325841408> because maybe it'd be useful for him. <https://github.com/easymodo/qimgv/releases/tag/v1.0.2>
|
|
2023-11-06 04:22:16
|
Not sure if this build supports jxl tho
|
|
|
Halfonso
|
2023-11-06 04:24:16
|
Thank you, but I already tried it and it gave me problems, it is the best I have tried so far, the problem I have is some random lags and that it messes up my photographs (when I open them from Windows Explorer they are ordered by date and other photo viewers respect the order)
|
|
2023-11-06 04:26:25
|
if imageglass could play video it would be perfect
|
|
|
fab
|
|
surpsingly, many of the others took very long to open and display the image...
|
|
2023-11-06 05:18:09
|
If you want Speed 1 Windows viewer win 7 2 JPEGview
|
|
2023-11-06 05:18:33
|
3. Xnview MP 1.22
|
|
|
|
_wb_
|
2023-11-07 02:48:19
|
https://fcbayern.com/
http://luisaviaroma.com/
https://www.suitsupply.com/
https://about.nike.com/
Some Cloudinary customers who are serving jxl images right now (I was just browsing some logs)
|
|
|
|
lonjil
|
2023-11-07 03:14:49
|
Not sure how Cloudinary selects which format to serve, but just checking in Safari and I'm getting JXLs!
|
|
2023-11-07 03:15:10
|
Have you got any numbers on JXL usage you can share?
|
|
|
|
_wb_
|
2023-11-07 03:29:20
|
When using f_auto and the customer has opted in to enabling jxl, we return jxl or a fallback format depending on the `Accept` headers the browser sends in the request
|
|
|
|
lonjil
|
2023-11-07 03:41:44
|
Aha, so these sites have all opted in. Pretty decent evidence that there is in fact industry interest.
|
|
|
|
_wb_
|
2023-11-07 03:56:58
|
At some point we might decide to make jxl enabled by default in f_auto, for now it's still opt-in.
|
|
|
|
HCrikki
|
2023-11-07 03:57:31
|
shouldnt jxl be prioritized for supported browsers/apps? cant imagine many go the extra mile to enable it. defaults are powerful
|
|
|
|
_wb_
|
2023-11-07 03:58:12
|
Currently (numbers from Oct 31), a bit over 7% of the requests we see accept image/jxl (almost all are safari, of course)
|
|
|
HCrikki
shouldnt jxl be prioritized for supported browsers/apps? cant imagine many go the extra mile to enable it. defaults are powerful
|
|
2023-11-07 04:14:04
|
Yes, but we prefer to move carefully before changing defaults to include new stuff — we need to make sure there are no bugs at our end, no bugs in Safari, etc. For now it's still opt-in, so early-adopters only.
|
|
2023-11-07 04:17:24
|
We are currently serving about 750,000 jxl images per day. That's still peanuts, but it's a start to see if everything is working fine.
|
|
2023-11-07 04:18:51
|
If we would globally switch on jxl in f_auto right now, we would be serving more than 1000x that many jxl images, something close to 1 billion images served per day.
|
|
|
|
Quackdoc
|
2023-11-07 04:20:14
|
~~oh no, I sneezed~~
|
|
|
|
_wb_
|
2023-11-07 04:20:44
|
(we serve about 15 billion images per day, and on October 31, we had 7.26% of the requests coming from a browser that accepts jxl)
|
|
2023-11-07 04:22:08
|
7.26% is not bad, beginning of September it was only 0.18% 🙂
|
|
|
|
MSLP
|
|
_wb_
7.26% is not bad, beginning of September it was only 0.18% 🙂
|
|
2023-11-07 04:24:50
|
quite a lot, considering <https://caniuse.com/jpegxl> reports ~3.2%
|
|
|
|
_wb_
|
2023-11-07 04:25:01
|
I wonder what percentage it will stabilize at, when everyone has an updated iOS / Safari. Safari is supposed to have ~20% market share worldwide, but I'm not sure if we have representative demographics
|
|
|
MSLP
quite a lot, considering <https://caniuse.com/jpegxl> reports ~3.2%
|
|
2023-11-07 04:26:24
|
Maybe those statcounter numbers are a bit older. End of September we also had something like that.
|
|
|
|
jonnyawsom3
|
2023-11-07 04:27:34
|
caniuse was reading 0.27% for a very long time, I think it only updates monthly
|
|
|
|
lonjil
|
2023-11-07 04:29:36
|
Let's see. Anyone who updates to the newest macOS or iOS will have JXL. Safari is updated for older versions of macOS for 3 years. Most iPhone users probably have phones that are still getting major updates, and will probably be moving to 17 or later within a year or two. Hm. Complete asspull number: I'm guessing about 15% within a year, with a slower tail for the remainder.
|
|
|
|
MSLP
|
|
_wb_
I wonder what percentage it will stabilize at, when everyone has an updated iOS / Safari. Safari is supposed to have ~20% market share worldwide, but I'm not sure if we have representative demographics
|
|
2023-11-07 04:32:27
|
I was betting on around 12% total, based on the assumption that half of the users who uses older safari/iOS will migrate to the newest version
|
|
|
|
Quackdoc
|
2023-11-07 04:34:00
|
considering how good apple is with updates, and their consumer base, thats quote the conservative estimate
|
|
|
|
HCrikki
|
2023-11-07 05:11:15
|
many users would be consuming jxl inside apps rendering a webview. i recollect facebook mentioned in the chromium bugtracker last year they hoped to consume jxl first in their mobile apps. this kind of traffic is almost never accounted for correctly and minimizes everything else's traffic (like firefox') since for every user with one favoured browser theyd have multiple electron-like apps
|
|
|
|
jonnyawsom3
|
2023-11-07 05:19:30
|
That depends on if Facebook still maintained the backend JXL support all this time and 'flipped the switch' when Apple announced it
|
|
|
w
|
2023-11-07 05:39:12
|
hi can I request cloudinary API to list assets in a folder that works
|
|
|
|
MSLP
|
|
HCrikki
many users would be consuming jxl inside apps rendering a webview. i recollect facebook mentioned in the chromium bugtracker last year they hoped to consume jxl first in their mobile apps. this kind of traffic is almost never accounted for correctly and minimizes everything else's traffic (like firefox') since for every user with one favoured browser theyd have multiple electron-like apps
|
|
2023-11-07 05:43:26
|
Too bad google removed jxl handling code completly, instead of just not enabling it in chrome.
Electron patches chromium, but the biggest patch size is ~40KB, and total size of patches is below ~630 KB
patch from uazo/chromite for restoring jxl is quite big compared to this
`00Add-support-to-jxl.patch 112.26 KB`
and then there's also patch with libjxl code
`00libjxl-0-8-2.patch 6.68 MB`
This means chances for adopting jxl support into electron aren't high, which in turn blocks electron apps which could use it
eg. <https://github.com/ollm/OpenComic/issues/165>
|
|
2023-11-07 05:54:02
|
js polyfil is an option in this case, but official stable build of it could be useful, because building it seems to be pain in the ass
|
|
|
|
_wb_
|
|
w
hi can I request cloudinary API to list assets in a folder that works
|
|
2023-11-09 03:51:13
|
I don't know about that API but if something is not working or you can't figure out how, just open a support ticket, there are Actual People (tm) responding to those 🙂
|
|
|
|
Traneptora
|
|
veluca
we should probably do that
|
|
2023-11-13 09:50:40
|
<@179701849576833024>
https://github.com/libjxl/libjxl/pull/2942
|
|
2023-11-13 09:50:43
|
took a bit longer but I sent it
|
|
|
|
veluca
|
2023-11-13 09:52:53
|
yeah just saw that
|
|
2023-11-13 09:53:11
|
it feels somewhat less ideal, as it quantizes to 8 bit unconditionally
|
|
2023-11-13 09:53:18
|
(compared to manually converting)
|
|
|
|
Traneptora
|
2023-11-13 09:53:22
|
gdk-pixbuf only supports 8
|
|
2023-11-13 09:53:38
|
if you try to allocate it with 16 it fails
|
|
|
|
veluca
|
2023-11-13 09:53:40
|
ah I mean compared to converting *first*
|
|
2023-11-13 09:53:46
|
and then converting to 8 bit
|
|
|
|
Traneptora
|
2023-11-13 09:53:49
|
that's true, but converting first is *very* slow
|
|
|
|
veluca
|
2023-11-13 09:54:02
|
it shouldn't be with the CMS API 🙂
|
|
|
|
Traneptora
|
2023-11-13 09:54:19
|
well, according to <@604964375924834314> it's most of the load time
|
|
|
|
veluca
|
2023-11-13 09:54:21
|
(there's a pending PR for that)
|
|
2023-11-13 09:54:38
|
(https://github.com/libjxl/libjxl/pull/2827)
|
|
2023-11-13 09:54:57
|
however... it's not like we can know what colorspace the image will be displayed in
|
|
2023-11-13 09:55:10
|
so the conversion to 8 bit might just be something we have to do
|
|
|
|
spider-mario
|
2023-11-13 09:55:28
|
the two changes are probably good to have together
|
|
2023-11-13 09:56:00
|
we can try to convert back to c_orig if possible, _and_ signal that
|
|
2023-11-13 09:56:27
|
thereby supporting wider gamuts than sRGB
|
|
|
|
Traneptora
|
2023-11-13 09:56:31
|
so maybe add this line? I was flipping back and forth on it
|
|
2023-11-13 09:56:34
|
```c
JxlColorEncoding color_encoding;
if (JXL_DEC_SUCCESS == JxlDecoderGetColorAsEncodedProfile(decoder_state->decoder,
JXL_COLOR_PROFILE_TARGET_ORIGINAL, &color_encoding)) {
// we don't check the return status here because it's not a problem if this fails
JxlDecoderSetPreferredColorProfile(decoder_state->decoder, &color_encoding);
}
```
|
|
2023-11-13 09:57:07
|
that way if we have a PQ image we request it in PQ?
|
|
2023-11-13 09:57:14
|
and a PQ icc profile?
|
|
2023-11-13 09:57:28
|
not sure if that is ideal if the monitor is sRGB though
|
|
2023-11-13 09:58:01
|
if the monitor is sRGB, then requesting an sRGB profile+data is ideal
|
|
2023-11-13 09:58:11
|
if the monitor is HDR then requesting wide-gamut profile+data is ideal
|
|
2023-11-13 09:58:15
|
and I don't think we have that info
|
|
|
|
veluca
|
2023-11-13 10:11:25
|
it could also be wider gamut but not sRGB
|
|
2023-11-13 10:11:36
|
or calibrated with some unknown profile
|
|
|
spider-mario
we can try to convert back to c_orig if possible, _and_ signal that
|
|
2023-11-13 10:14:14
|
that seems like the best option yeah
|
|
2023-11-13 10:14:38
|
which would still benefit from the CMS stuff
|
|
|
|
Traneptora
|
|
veluca
that seems like the best option yeah
|
|
2023-11-13 10:54:46
|
in that case I can modify my PR above to add the above block of code?
|
|
|
|
veluca
|
2023-11-13 10:55:37
|
if you can also make it work with the CMS API it'd be best
|
|
2023-11-13 10:55:42
|
(that should be ready very soon)
|
|
|
|
Traneptora
|
2023-11-13 10:56:23
|
in that case I might just wait for your merge
|
|
|
|
_wb_
|
|
_wb_
7.26% is not bad, beginning of September it was only 0.18% 🙂
|
|
2023-11-15 07:55:19
|
Update with numbers from last week: we're currently serving about one million jxl images per day. We are now seeing a bit over 8% of image requests coming from user agents that accept jxl.
|
|
|
Dexrn ZacAttack
|
|
_wb_
(we serve about 15 billion images per day, and on October 31, we had 7.26% of the requests coming from a browser that accepts jxl)
|
|
2023-11-15 09:15:22
|
How do you find this out?
|
|
|
|
_wb_
|
2023-11-15 09:16:39
|
by querying the CDN logs
|
|
|
|
yoochan
|
|
Dexrn ZacAttack
How do you find this out?
|
|
2023-11-15 07:18:01
|
when _wb_ says we, it implies : cloudinary, which is the company he works for, hence the access to the stats 🙂
|
|
|
|
Dexrn ZacAttack
|
|
yoochan
when _wb_ says we, it implies : cloudinary, which is the company he works for, hence the access to the stats 🙂
|
|
2023-11-15 07:18:22
|
I mean like what website is he grabbing the info from
|
|
|
|
yoochan
|
2023-11-15 07:18:35
|
the cloudinary's cdn
|
|
|
|
Dexrn ZacAttack
|
|
yoochan
the cloudinary's cdn
|
|
2023-11-15 07:19:55
|
For some reason I'm kinda confused, obviously he doesnt have access to statistics of EVERY JXL image that has been on the internet, but is that really a big enough CDN with that many JXLs?
|
|
|
|
yoochan
|
2023-11-15 07:21:10
|
cloudinary IS a big cdn, but not the only one. Even if it is partial information it still means that 8% of browsers which happen to browse content hosted by it accept Jpeg XL
|
|
2023-11-15 07:22:02
|
like when a poll is done on a sample but we extrapolate the results to the whole population, it is an indicator. Not a perfect one, but it makes us proud nonetheless
|
|
|
|
username
|
2023-11-15 07:28:37
|
also something important to note is CDNs usually auto convert images to other formats based on various factors meaning that if a website is serving images through a CDN and those images where originally PNGs and JPEGs they won't get sent to people visiting the website as the original format. People aren't actively uploading JXLs to Cloudinary, Cloudinary is actively converting images to JXLs and other formats (the original image files are still stored on the servers)
|
|
|
|
Dexrn ZacAttack
|
|
yoochan
cloudinary IS a big cdn, but not the only one. Even if it is partial information it still means that 8% of browsers which happen to browse content hosted by it accept Jpeg XL
|
|
2023-11-15 07:48:10
|
Interesting
|
|
|
|
spider-mario
|
|
yoochan
like when a poll is done on a sample but we extrapolate the results to the whole population, it is an indicator. Not a perfect one, but it makes us proud nonetheless
|
|
2023-11-15 07:49:54
|
the late E. T. Jaynes has a nice section on this in his book on probability theory:
|
|
2023-11-15 07:50:20
|
perhaps a more day-to-day example is when we taste soup to see if it has the right amount of salt
|
|
2023-11-15 07:50:38
|
provided that it’s sufficiently stirred, we don’t need to eat the whole pot for that
|
|
|
|
_wb_
|
2023-11-16 07:34:29
|
Data from November 14:
8.71% of the image requests came from a user agent that accepts `image/jxl`
We served 16.8 billion images on that day, and in 1.46 billion cases it was from a browser that can handle jxl.
|
|
|
|
Cacodemon345
|
2023-11-16 09:08:31
|
Now if only Google finally caved in after getting into hard times with popularity of Android over iOS in the US.
|
|
|
|
Demiurge
|
2023-11-16 07:28:52
|
Well I guess I am going to get an Apple phone again...
|
|
2023-11-16 07:29:48
|
I hope there will be more third party implementations of the encoder and decoder
|
|
2023-11-16 07:30:24
|
Especially ones that are optimized for memory use or readability.
|
|
|
|
Quackdoc
|
2023-11-16 08:05:33
|
im waiting patiently, Slint is a rust based UI framework and they recently added support for android, so when it matures a bit more I wanna try and write a gallery app using it
|
|
|
VEG
|
2023-11-16 10:43:18
|
JXL support is cool, but not being able to choose your software without blessing from Apple, it's...
|
|
2023-11-16 10:43:27
|
Well, some people like dictatorships
|
|
|
|
veluca
|
|
VEG
JXL support is cool, but not being able to choose your software without blessing from Apple, it's...
|
|
2023-11-16 10:44:04
|
that will supposedly change before March in Europe
|
|
|
|
VEG
|
2023-11-16 10:48:07
|
We'll see, but Apple being Apple, they'll always find a way to do their thing
|
|
|
|
spider-mario
|
2023-11-16 11:04:47
|
continuing to get security updates for models that came out 8 years ago is nice, though
|
|
2023-11-16 11:05:44
|
this is in stark contrast with the Sony phone I bought which stopped receiving them within two years of my buying it
|
|
2023-11-16 11:05:51
|
(I bought it a year after it came out, but still)
|
|
2023-11-16 11:13:13
|
(XZ2 Compact, released April 2018, bought May 2019, last security update in August 2020)
|
|
|
|
VcSaJen
|
2023-11-17 01:05:51
|
JPEG XL support is added to OpenSource CDN code:
https://github.com/Pixboost/transformimgs
|
|
|
|
Demiurge
|
2023-11-17 01:49:49
|
https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985
I was just re-reading this and I was wondering, who is this "we" that Martin Thomson supposedly "consulted" with?
|
|
2023-11-17 01:50:56
|
As in, who is ultimately actually in charge of making the decision for mozilla's position on this?
|
|
|
|
w
|
2023-11-17 01:51:32
|
someone at Google probably
|
|
|
|
Demiurge
|
2023-11-17 07:10:32
|
That's what it makes me think when he uses such vague weasely language like that Bankowski guy
|
|
|
|
Traneptora
|
|
spider-mario
we can try to convert back to c_orig if possible, _and_ signal that
|
|
2023-11-19 02:19:42
|
just pushed that change
|
|
|
|
veluca
|
2023-11-19 11:06:55
|
nice!
|
|
2023-11-19 11:07:01
|
will review that soonish
|
|
|
|
Demiurge
|
2023-11-20 09:02:03
|
Is there a widget toolkit or ui builder, preferably cross platform, that someone would recommend for rapid prototyping and development of a simple GUI frontend for noobs to convert their images to JXL? I was thinking of using Perl for the program logic. It would be ideal if it works well on macOS, for obvious reasons.
|
|
|
|
spider-mario
|
2023-11-20 09:13:24
|
Qt would be my go-to but perhaps involves more learning than you’d like
|
|
2023-11-20 09:13:32
|
https://www.xojo.com/ might also be an option
|
|
|
|
Demiurge
|
2023-11-20 09:21:38
|
I was thinking it might be easier to have no UI at all and just make a dragon drop script :) But that might be slightly less user friendly and I want all the computer illiterate people to be able to start using jpegxl
|
|
2023-11-20 09:27:07
|
Well, I might not need to write the logic in Perl either...
|
|
2023-11-20 09:42:51
|
My plan is to make a simple little tool, for anybody, close to foolproof, using libvips or magick to decode input files and exiftool to handle the metadata, so that way people can just throw whatever format they want and get a jpegxl file that keeps all their metadata intact regardless of the input format. And also have the ability to restore recompressed JPEG back to the original JPEG file. In the most convenient and foolproof way possible, since there seems to be a lot of newbies having trouble converting their files back and forth.
|
|
2023-11-20 09:43:17
|
And, at this stage of adoption, I feel like the more jpegxl usage and files there are out in the wild, the better for the future of the format.
|
|
2023-11-20 09:44:59
|
Most people have never heard of jpegxl before and never encountered a file. The more awareness there is of the format, the more successful I feel it will be in the long run, if general awareness is increased today, since it is already at a stage where it can benefit the average person.
|
|
2023-11-20 09:45:25
|
As long as there are foolproof tools that the average person can use.
|
|
2023-11-20 09:46:19
|
So in other words, I think tooling is the most important thing right now, aside from web browser support or improved lossy compression.
|
|
2023-11-20 09:51:00
|
Tooling is probably more important than anything because improved tooling with increase usage and the chances of people being casually exposed to the existence of jpegxl, and increased awareness of the existence of jpegxl will increase the chances that someone will add support for it in third party software, or even write optimized encoders/decoders if we're luckier.
|
|
|
|
spider-mario
|
2023-11-20 11:37:48
|
doing it in perl might make it tricky for people to even install
|
|
|
Pieter
|
|
spider-mario
doing it in perl might make it tricky for people to even install
|
|
2023-11-21 02:11:03
|
... or read 😝
|
|
2023-11-21 02:11:23
|
(I say this as someone who used to love Perl)
|
|
|
|
Demiurge
|
2023-11-21 07:20:34
|
Well, I might not need to write the logic in Perl, since all of the libraries I plan of using, including exiftool, have bindings for other languages.
|
|
2023-11-21 07:23:17
|
Lots of things about Qt seem like extreme red flags to me, like heavy reliance on soydev technology like C++ and CMake...
|
|
|
|
Traneptora
|
2023-11-21 07:24:14
|
where did that come from
|
|
2023-11-21 07:24:43
|
this is <#803574970180829194>
|
|
|
|
Demiurge
|
2023-11-21 07:26:31
|
I'm researching widget toolkits... Maybe further ruminations would be better in <#803663417881395200>?
|
|
|
190n
|
|
Demiurge
Lots of things about Qt seem like extreme red flags to me, like heavy reliance on soydev technology like C++ and CMake...
|
|
2023-11-21 07:26:42
|
define "soydev"
|
|
|
|
Demiurge
|
|
190n
define "soydev"
|
|
2023-11-21 07:28:27
|
People who don't understand the tools they are using and don't know how to choose the right tool for the job, but just do what everyone else is doing because it's what they were taught how to do and it's what looks popular.
|
|
|
|
w
|
2023-11-21 07:28:42
|
<:okay_retard:575425279883739136>
|
|
|
|
Traneptora
|
2023-11-21 07:28:58
|
here he goes again
|
|
|
|
190n
|
|
Demiurge
People who don't understand the tools they are using and don't know how to choose the right tool for the job, but just do what everyone else is doing because it's what they were taught how to do and it's what looks popular.
|
|
2023-11-21 07:33:50
|
why soy
|
|
|
|
Demiurge
|
2023-11-21 07:34:45
|
that's the common parlance.
|
|
|
|
spider-mario
|
|
190n
why soy
|
|
2023-11-21 07:35:01
|
presumably because of what is described here: https://youtu.be/C8dfiDeJeDU
|
|
|
|
190n
|
2023-11-21 07:36:35
|
yeah i think i've seen that
|
|
|
|
Demiurge
|
2023-11-21 07:38:23
|
I don't know if I have seen that video before, but I doubt it actually talks about "soydev"
|
|
2023-11-21 07:39:42
|
Honestly I'm not sure if I want to see it, given the thumbnail, and the half an hour length...
|
|
|
|
190n
|
2023-11-21 07:44:48
|
are the libjxl developers soydevs?
|
|
|
|
Demiurge
|
2023-11-21 07:48:40
|
It's the term I see people use for devs that seem to just go with the crowd and do things in supremely inefficient ways since that's what everyone else is doing and they don't know anything else.
I can't speak for every libjxl developer but veluca wrote fjxl in C and wb wrote libfuif in C which was incorporated into libjxl... libjxl seems to have inherited its dependency-heavy C++ codebase from the Google PIK tree.
|
|
2023-11-21 07:50:43
|
A lot of developers including Jyrki seem to be signal processing specialists and contribute improvements to improving the way the image data is encoded and stored
|
|
|
|
w
|
2023-11-21 07:51:06
|
C is for soydevs. You should be using fortran or BASIC
|
|
|
|
Demiurge
|
2023-11-21 07:51:32
|
;( If you're not using plan9 you're probably too far gone already
|
|
2023-11-21 07:54:52
|
In all seriousness though I don't think it makes sense to make that kind of comparison.
|
|
2023-11-21 07:55:36
|
Since C is not any more complicated than those other languages.
|
|
|
|
veluca
|
|
Demiurge
It's the term I see people use for devs that seem to just go with the crowd and do things in supremely inefficient ways since that's what everyone else is doing and they don't know anything else.
I can't speak for every libjxl developer but veluca wrote fjxl in C and wb wrote libfuif in C which was incorporated into libjxl... libjxl seems to have inherited its dependency-heavy C++ codebase from the Google PIK tree.
|
|
2023-11-21 07:56:42
|
pretty sure I wrote fjxl in C++, and IIRC so was libfuif 😛
|
|
|
|
Demiurge
|
2023-11-21 07:58:52
|
Maybe I had a weird dream that I checked the source code for both and saw it written in C...
|
|
|
|
w
|
2023-11-21 07:59:03
|
real video of pashifox https://www.youtube.com/watch?v=wKm8rVaZfqg
|
|
|
|
Demiurge
|
2023-11-21 07:59:36
|
Is that Terry Davis?
|
|
2023-11-21 08:00:56
|
Well, he was chosen by God, of course he's a good programmer.
|
|
|
|
w
|
2023-11-21 08:01:57
|
https://www.youtube.com/watch?v=4K8IEzXnMYk
|
|
2023-11-21 08:01:58
|
so true
|
|
|
|
Demiurge
|
2023-11-21 08:03:26
|
Oh, I see. libfuif was indeed written in C++ but I got it mixed up in my memory because the code style is very close to a traditional C project.
|
|
2023-11-21 08:04:16
|
Actually, it uses very little C++ features at all.
|
|
2023-11-21 08:04:41
|
It doesn't even use C++ headers. It uses the C standard library instead.
|
|
2023-11-21 08:05:00
|
For example: https://github.com/cloudinary/fuif/blob/master/io.cpp
|
|
2023-11-21 08:06:08
|
That's why I got it mixed up in my memories.
|
|
|
|
w
|
2023-11-21 08:07:40
|
it uses plenty of c++ features
|
|
|
|
Demiurge
|
2023-11-21 08:08:11
|
Like the bool type?
|
|
|
|
w
|
2023-11-21 08:08:20
|
like classes templates and the stl
|
|
|
|
Demiurge
|
2023-11-21 08:10:07
|
When I was looking over some of the source, I didn't notice a lot of stuff like that.
|
|
2023-11-21 08:10:34
|
I probably didn't look at it for as long as you did.
|
|
|
|
w
|
2023-11-21 08:10:51
|
i only looked at 2 files
|
|
|
|
Demiurge
|
2023-11-21 08:16:45
|
The same thing also must have happened in my memory when I was looking at fjxl. It's also coded in C++ but with thoughtful usage of its features.
|
|
|
|
w
|
2023-11-21 08:17:24
|
you just proved that the language doesnt matter
|
|
|
|
Demiurge
|
2023-11-21 08:17:24
|
And effective
|
|
2023-11-21 08:19:20
|
It matters less, when in the hands of someone who knows what they're doing using it in a thoughtful and effective way.
|
|
|
|
w
|
2023-11-21 08:20:01
|
what is your point
|
|
|
|
Demiurge
|
2023-11-21 08:20:34
|
It still kinda matters when porting the compiler to a new platform or when learning the language.
|
|
2023-11-21 08:21:07
|
But this channel probably isn't the right place for that topic
|
|
2023-11-21 08:36:52
|
Still my gut is telling me to stay away from Qt...
|
|
|
|
Traneptora
|
2023-11-21 11:08:34
|
well my gut tells me that glib avoids valgrind and leaks memory and that Qt doesn't
|
|
2023-11-21 11:08:45
|
and by my gut I mean my valgrind usage
|
|
|
|
Demiurge
|
2023-11-21 11:27:29
|
I'm pretty sure I should stay far away from glib anything too.
|
|
2023-11-21 11:29:01
|
I might actually go with Java...
|
|
2023-11-21 11:29:17
|
As cringe as that sounds
|
|
2023-11-21 11:30:52
|
:(
|
|
|
|
VEG
|
2023-11-21 09:35:25
|
Try C#, it's nicer than Java
|
|
|
|
Posi832
|
2023-11-21 09:38:46
|
Use redstone
|
|
|
|
Oleksii Matiash
|
|
VEG
Try C#, it's nicer than Java
|
|
2023-11-22 07:00:30
|
Try kotlin, much nicer than both
|
|
|
|
Demiurge
|
2023-11-22 09:10:13
|
That was one of the things I was considering, since it says it has a cross platform UI library, which is exactly what I'm looking for... It just seems kind of too good to be true since I have never seen any kotlin apps on a (Windows, Apple, UNIX) PC
|
|
|
|
VcSaJen
|
|
|
Traneptora
|
|
Demiurge
That was one of the things I was considering, since it says it has a cross platform UI library, which is exactly what I'm looking for... It just seems kind of too good to be true since I have never seen any kotlin apps on a (Windows, Apple, UNIX) PC
|
|
2023-11-23 03:06:34
|
Kotlin targets the JVM, not native code, so it has access to anything that the JVM has access to, such as Swing
|
|
|
|
jonnyawsom3
|
2023-11-24 04:02:04
|
Hopefully it isn't held back until a major release, since they're only once a year or more
https://github.com/LibRaw/LibRaw/issues/615
|
|
|
|
MSLP
|
2023-11-27 05:36:52
|
Netsurf browser is implementing JPEG XL support via libjxl
https://github.com/netsurf-browser/netsurf/commit/dbe5d1ef87ff5a348ae758bdb9635f767822d7d4
So hopefully someday RiscOS users will be able view jxl images on the web 🤪
Sadly the last binary release of Netsurf (3.10) was in may 2020, so that may take a while.
|
|
|
|
Quackdoc
|
2023-11-27 05:42:36
|
Netsurf is still a thing!? I thought it died in 09
|
|
|
|
MSLP
|
2023-11-27 05:46:12
|
Apparently it somewhat is, no binary releases for more than 3 years tho, and they used to release at least yearly
|
|
|
|
username
|
2023-11-30 10:51:07
|
This stuff has been sitting dormant since 2022:
https://github.com/sumatrapdfreader/sumatrapdf/issues/1943
https://sumatrapdf.canny.io/feature-requests/p/support-jpeg-xl-image-format
|
|
2023-11-30 10:52:08
|
might be worth it to vote up on the Canny feature request post?
|
|
|
eddie.zato
|
2023-12-01 07:30:04
|
At the same time I remember filling same issue to mupdf bugtracker about jxl support. They replied "if pdf supports it, we will add it as well". Now I can't even find that issue, it just disappeared.
|
|
|
|
runr855
|
2023-12-01 02:03:20
|
Does anyone have any inkling if the PDF ISO committee is working on including JXL? A better image format would make sense in PDF, and JXL is clearly superior to AVIF in the context of PDF
|
|
|
|
_wb_
|
2023-12-01 02:54:17
|
I think they're planning to have JXL in one of the future PDF specs.
|
|
|
|
Cacodemon345
|
2023-12-01 03:48:20
|
I doubt it will be enough to change Google's stance on it.
|
|
|
|
Quackdoc
|
2023-12-01 03:55:47
|
I still think it's early for chrome devs to have had their hand forced. the best thing to do is start making websites so we can claim that chrome and firefox are broken on them
|
|
|
|
Cacodemon345
|
2023-12-01 04:13:58
|
It is going to have the exact opposite effect.
|
|
2023-12-01 04:14:26
|
Safari (and WebKit) users are minuscle.
|
|
2023-12-01 04:14:45
|
Not many people even use Macs to begin with.
|
|
|
|
Quackdoc
|
2023-12-01 04:15:09
|
historically, no it has for sure worked. If you want to, you can implement a wasm decoder and just print a warning. but the best way to get a format to have popularity, is to get people using the format
|
|
|
|
Cacodemon345
|
2023-12-01 04:15:57
|
I think a fast WASM decoder will be the way to go for JXL ultimately.
|
|
|
|
Quackdoc
|
2023-12-01 04:16:58
|
I dont think you can realisitcally make a good wasm decoder fast enough
|
|
|
|
lonjil
|
|
Cacodemon345
Safari (and WebKit) users are minuscle.
|
|
2023-12-01 04:21:30
|
20% is not miniscule. Half of all smartphones in the US. Macs are less popular but they're still pretty popular.
But yes you're not going to make the majority player (Google) do something by excluding them in favor of a minority player (Apple).
I expect many websites to adopt JXL without adopting AVIF, though.
|
|
|
|
Quackdoc
|
2023-12-01 04:22:58
|
you arent exlcuding them, you are forcing their hand, there is a significant difference. you can't spam google for a feature request, you can spam them for every single broken site out there. and users are also well within their right to report a website as broken
|
|
|
|
HCrikki
|
2023-12-01 04:23:30
|
One way to smooth adoption would be websites offering jxl for download even if theyre not viewable. Even jpegxl.info doesnt do that right now, unless you play with image urls you have no direct way to obtain jxl images where they exist
|
|
|
|
lonjil
|
|
Quackdoc
you arent exlcuding them, you are forcing their hand, there is a significant difference. you can't spam google for a feature request, you can spam them for every single broken site out there. and users are also well within their right to report a website as broken
|
|
2023-12-01 04:23:53
|
if you make a website broken for 80% of users, they're gonna spam complaints *at you*, not at Google
|
|
|
|
Quackdoc
|
|
lonjil
if you make a website broken for 80% of users, they're gonna spam complaints *at you*, not at Google
|
|
2023-12-01 04:25:24
|
no actually. If you give nice big warning saying "this site may not render correctly on browsers without x I reccomend updating" they really dont
|
|
|
|
afed
|
2023-12-01 04:27:59
|
yeah, webp has gotten a lot of negative attention because of this
and for a lot of people it's rather become the most hated format
though jxl has better support in editors and tools from the beginning
|
|
|
|
Quackdoc
|
2023-12-01 04:29:41
|
it because a hated format because of two reasons.
A) every implementation of it is buggy which has caused apps and devices to actively go out of their way to disable support.
B) despite this websites pretend an image is a jpg or a png so when you download the "PNG" from a website but it's actually webp, see point A as to why thats bad
|
|
2023-12-01 04:30:15
|
and well, even if it was the case, can't say it didnt work, nearly every site serves webp
|
|
2023-12-01 04:36:55
|
that being said, wasm is for sure a potential avenue. wasm can be really buggy, slow down webpage down to a halt, and even crash a browser (haha L firefox users) if the decoder gets overwhelmed. I actually find JXL-oxide to be better at wasm because for some reason, the webbrowser remains responsive, even if images stop rendering (after being decoded, they get sent to the browser as a base64 to be rendered.) while larger images and decoding for some reason, I think this is just an inherent flaw of webbrowsers and poor threading
|
|
|
|
Cacodemon345
|
|
lonjil
20% is not miniscule. Half of all smartphones in the US. Macs are less popular but they're still pretty popular.
But yes you're not going to make the majority player (Google) do something by excluding them in favor of a minority player (Apple).
I expect many websites to adopt JXL without adopting AVIF, though.
|
|
2023-12-01 05:30:56
|
People outside the US generally ignore iPhones and Macs.
|
|
2023-12-01 05:32:23
|
What would be better is finishing jxl-oxide to allow images-rs to import it.
|
|
|
|
MSLP
|
|
Cacodemon345
What would be better is finishing jxl-oxide to allow images-rs to import it.
|
|
2023-12-01 05:37:45
|
it is quite ready for inclusion, but currently the issue is paywalled format specification https://github.com/image-rs/image/issues/1979#issuecomment-1826870586
|
|
|
|
Cacodemon345
|
2023-12-01 06:01:06
|
There's no ETA on the free spec even.
|
|
|
|
lonjil
|
|
Cacodemon345
People outside the US generally ignore iPhones and Macs.
|
|
2023-12-01 06:11:21
|
that's just not true. The US is one of Apple's best markets, but in e.g. China iPhones have 25% of the market, in Germany ~35%, in the UK 50%, I think 55% here in Sweden. Globally iPhone is like 20 to 30 % depending on who's measuring.
|
|
|
|
Cacodemon345
|
2023-12-01 06:13:05
|
That's solely for the developed markets, not developing ones.
|
|
|
|
afed
|
2023-12-01 06:13:52
|
but, aren't the past versions of the specification still basically free?
and the recent ones have only some corrections that are not so important for a full understanding (which can also be clarified from the sources if it is really needed)
|
|
|
|
lonjil
|
2023-12-01 06:14:02
|
yes, poorer country's have much fewer iPhone users, that's why it averages out to 25%ish
|
|
|
afed
but, aren't the past versions of the specification still basically free?
and the recent ones have only some corrections that are not so important for a full understanding (which can also be clarified from the sources if it is really needed)
|
|
2023-12-01 06:14:28
|
isn't the last public draft really old and different?
|
|
|
|
Cacodemon345
|
|
lonjil
yes, poorer country's have much fewer iPhone users, that's why it averages out to 25%ish
|
|
2023-12-01 06:15:24
|
And that makes nearly the rest Android users.
|
|
|
|
Quackdoc
|
|
Cacodemon345
That's solely for the developed markets, not developing ones.
|
|
2023-12-01 06:15:55
|
why would that even matter?
|
|
2023-12-01 06:16:20
|
are developed countries worth less then non developed ones?
|
|
|
|
lonjil
|
|
Cacodemon345
And that makes nearly the rest Android users.
|
|
2023-12-01 06:17:28
|
I really don't understand what point you're trying to make. It doesn't seem relevant to anything I've said.
|
|
|
|
Cacodemon345
|
2023-12-01 06:19:52
|
The point being that the vast majority of smartphone users around the world are Android users, and therefore, won't be enjoying JPEG XL support, which means that it's pointless for websites to support it even.
|
|
|
|
Quackdoc
|
2023-12-01 06:20:36
|
isnt iphone estimated to be around 30% global usage? that is way more then enough to be massively significant
|
|
|
|
Cacodemon345
|
2023-12-01 06:21:11
|
It still isn't enough to force Google into adding JPEG XL support.
|
|
|
|
Quackdoc
|
2023-12-01 06:21:21
|
I significantly doubt that
|
|
|
|
Cacodemon345
|
2023-12-01 06:21:24
|
And we don't know which percentage is on pre-JXL iOS.
|
|
|
|
lonjil
|
2023-12-01 06:21:53
|
I've seen a few random websites that have already started using JXL
|
|
2023-12-01 06:22:13
|
that 20 to 30 % is definitely enough for websites to consider using it
|
|
|
|
Quackdoc
|
2023-12-01 06:22:26
|
you seem to be missing the point entirely, IMO, its worth it for some services to break optimal compatibility because the benefits of JXL, even to the "small" portion of users is actually nice
|
|
|
|
lonjil
|
2023-12-01 06:22:32
|
as for "forcing" google to do anything... lol. they're stubborn.
|
|
|
|
Quackdoc
|
|
lonjil
as for "forcing" google to do anything... lol. they're stubborn.
|
|
2023-12-01 06:22:48
|
hence needing to report sites as broken
|
|
|
|
fab
|
2023-12-01 06:23:14
|
Do you have seen a person in Italy at Penny market without an iPhone
|
|
|
|
Quackdoc
|
2023-12-01 06:23:14
|
a "nice feature" isnt important, "web compatibility" on the other hand is
|
|
|
|
lonjil
|
|
Quackdoc
hence needing to report sites as broken
|
|
2023-12-01 06:23:15
|
no, they'll just go to different websites
|
|
|
|
fab
|
2023-12-01 06:23:33
|
Every italian in the world knows how to write iPhone
|
|
|
|
lonjil
|
2023-12-01 06:23:38
|
the users will consider your website to be broken and not visit it
|
|
|
|
Quackdoc
|
2023-12-01 06:24:29
|
they dont. People are willing to report websites as broken, if you clearly lable "this site may not render properly on x browser, Please file a bug report or use a new browser". sure they may move on, but enough are willing to actually report the page as broken
|
|
|
|
fab
|
2023-12-01 06:24:44
|
I don't
|
|
2023-12-01 06:24:48
|
I love ads
|
|
|
|
Cacodemon345
|
2023-12-01 06:24:52
|
And then Google writes off those websites are broken.
|
|
|
|
Quackdoc
|
|
Cacodemon345
And then Google writes off those websites are broken.
|
|
2023-12-01 06:25:11
|
sure, in small ammounts yes, but google actually cares about webcompat
|
|
|
|
afed
|
|
lonjil
isn't the last public draft really old and different?
|
|
2023-12-01 06:25:39
|
even the old draft is not really different
and as far as I understand, after version updates, past versions can also be shared for public access (theoretically)
|
|
|
|
fab
|
|
afed
even the old draft is not really different
and as far as I understand, after version updates, past versions can also be shared for public access (theoretically)
|
|
2023-12-01 06:25:58
|
❤️
|
|
|
|
Cacodemon345
|
|
Quackdoc
sure, in small ammounts yes, but google actually cares about webcompat
|
|
2023-12-01 06:26:10
|
I mean I don't think they actually care about it as long as they still own W3C.
|
|
|
|
lonjil
|
|
Quackdoc
sure, in small ammounts yes, but google actually cares about webcompat
|
|
2023-12-01 06:27:27
|
website operators care about having users
|
|
2023-12-01 06:27:44
|
losing 80% of your users because you want to support a cool new file format is not something anyone will ever do
|
|
|
|
Cacodemon345
|
2023-12-01 06:28:37
|
Not to mention I have seen a rather negative sentiment against post-PNG image formats outside this place.
|
|
|
|
Quackdoc
|
2023-12-01 06:28:38
|
I havent seen anyone loose 80% of users because an image or two failed to load
|
|
|
|
lonjil
|
2023-12-01 06:29:33
|
so you're talking about websites whose images don't matter?
|
|
|
|
Quackdoc
|
2023-12-01 06:29:51
|
no, Im saying users are willing to forgive an image or two not loading and report them as broken
|
|
2023-12-01 06:29:58
|
just dont make the images super important ones
|
|
|
|
Cacodemon345
|
2023-12-01 06:30:15
|
Shopify and the like certainly doesn't have enough leverage to make Google add JPEG XL support.
|
|
|
|
Quackdoc
|
2023-12-01 06:30:30
|
and?
|
|
2023-12-01 06:30:44
|
Im missing the point here
|
|
2023-12-01 06:31:06
|
I mean if every shopify site were to break over night it would for sure, but shopify cant handle that kind of breakage
|
|
2023-12-01 06:31:10
|
it would bankrupt them
|
|
|
|
lonjil
|
2023-12-01 06:31:21
|
google would not care
|
|
|
|
Cacodemon345
|
|
Quackdoc
it would bankrupt them
|
|
2023-12-01 06:31:26
|
And finally you get the point.
|
|
|
|
Quackdoc
|
|
lonjil
google would not care
|
|
2023-12-01 06:31:43
|
they do, google actually **does** care about web compat
|
|
|
|
lonjil
|
2023-12-01 06:31:47
|
google might add jxl eventually, but it's never going to be due to anyone reporting sites as broken
|
|
|
|
Cacodemon345
|
2023-12-01 06:32:03
|
Then PDF?
|
|
|
|
Quackdoc
|
2023-12-01 06:32:05
|
in fact, google are some of the most active in making sure webcompat is good
|
|
|
|
lonjil
|
|
Quackdoc
they do, google actually **does** care about web compat
|
|
2023-12-01 06:32:12
|
you're treating web compat as a magic incantation
|
|
|
|
Quackdoc
|
|
lonjil
you're treating web compat as a magic incantation
|
|
2023-12-01 06:32:20
|
**because it is**
|
|
|
|
lonjil
|
|
|
Cacodemon345
|
2023-12-01 06:32:25
|
It hasn't existed in the post-Flash era.
|
|
|
|
Quackdoc
|
2023-12-01 06:32:26
|
that IS googles thing
|
|
|
|
lonjil
|
2023-12-01 06:32:42
|
no, google's thing is doing whatever they want and expecting others to follow
|
|
|
|
Cacodemon345
|
2023-12-01 06:32:47
|
Plugins got completely replaced with browsers.
|
|
2023-12-01 06:32:59
|
There's no Linux way anymore.
|
|
|
|
Quackdoc
|
|
lonjil
no, google's thing is doing whatever they want and expecting others to follow
|
|
2023-12-01 06:34:25
|
this isn't true, google is one of the more active people in ensuring web compat, to the extent that i've seen chrome push updates to fix sites I reported as broken that havent had updates in nearly a decade
|
|
|
|
lonjil
|
|
|
Quackdoc
|
2023-12-01 06:34:55
|
one of them was a really old blog about ambisonics from the windows xp era
|
|
|
|
lonjil
|
2023-12-01 06:34:59
|
that's the exact opposite situation
|
|
2023-12-01 06:35:15
|
they care about not fucking up stuff that were working
|
|
|
|
Quackdoc
|
2023-12-01 06:35:35
|
what they care about is web compatibility,
|
|
|
|
lonjil
|
2023-12-01 06:35:37
|
that does not mean that they care if some new thing that was never supported is broken
|
|
|
|
Quackdoc
|
|
lonjil
that does not mean that they care if some new thing that was never supported is broken
|
|
2023-12-01 06:35:49
|
they will if it effects enough users
|
|
|
|
lonjil
|
2023-12-01 06:36:16
|
it won't affect anyone, because no one will do this
|
|
2023-12-01 06:36:22
|
and anyone who tries will die
|
|
|
|
Quackdoc
|
2023-12-01 06:36:32
|
why would that? just don't do it like a retard
|
|
|
|
Cacodemon345
|
2023-12-01 06:36:38
|
Not while Safari remains outside Windows land.
|
|
|
|
Quackdoc
|
2023-12-01 06:36:55
|
i've already explained that the majority of users are willing to tollerate a degree of issues, as long as it's not a breaking experience
|
|
2023-12-01 06:37:11
|
I mean hell, some people still use IE and firefox for petes sake
|
|
|
|
lonjil
|
2023-12-01 06:37:16
|
no, you haven't explained anything. You've asserted thing.
|
|
|
Quackdoc
I mean hell, some people still use IE and firefox for petes sake
|
|
2023-12-01 06:37:23
|
🤨
|
|
|
|
MSLP
|
2023-12-01 06:37:26
|
I don't think actively-maintained websites owners will decide to push change crippling majority of users.
|
|
|
|
lonjil
|
2023-12-01 06:37:32
|
why are you putting IE and Firefox in the same category
|
|
|
|
Quackdoc
|
|
lonjil
why are you putting IE and Firefox in the same category
|
|
2023-12-01 06:38:03
|
because both have sites that break in comparison to "the standard" which would be chrome
|
|
|
|
190n
|
2023-12-01 06:38:26
|
chrome isn't the standard
|
|
|
|
lonjil
|
2023-12-01 06:38:37
|
I can assure you that Firefox users avoid websites that don't work on Firefox.
|
|
|
|
Quackdoc
|
|
lonjil
I can assure you that Firefox users avoid websites that don't work on Firefox.
|
|
2023-12-01 06:38:56
|
no idea about you, but I don't unless the website is completly unusable
|
|
|
190n
chrome isn't the standard
|
|
2023-12-01 06:39:09
|
sure it is, it's pretty much the browser to test for
|
|
2023-12-01 06:39:37
|
if it works on chrome it "works" is a sentiment i've come across lots
|
|
|
|
Cacodemon345
|
2023-12-01 06:40:06
|
Lowest common dominator is still WebKit; testing on Safari means you don't get complaints from iPhone users.
|
|
|
|
190n
|
|
Quackdoc
if it works on chrome it "works" is a sentiment i've come across lots
|
|
2023-12-01 06:40:20
|
sure but it is wrong
|
|
|
|
Quackdoc
|
2023-12-01 06:40:27
|
I mean, just look on the webcompat/web-bugs for this https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is%3Aopen+label%3Abrowser-firefox
which tbf, isn;t a *great* comparison because firefox are more likely to report bugs int he first place
|
|
|
190n
sure but it is wrong
|
|
2023-12-01 06:40:35
|
why? chrome dominates by a vast majority
|
|
|
|
190n
|
2023-12-01 06:40:53
|
if we let chrome be the standard we get shit like web integrity and manifest v3 and topics
|
|
|
|
Quackdoc
|
2023-12-01 06:41:15
|
tell firefox to do something to actually increase it's userbase instead of making them leave then xD
|
|
2023-12-01 06:41:49
|
but as it stands, you test for desktop and mobile chrome and iphone browser, the only two things a dev realisitcally needs to care about
|
|
|
|
Cacodemon345
|
2023-12-01 06:42:02
|
WebKit still is relevant; though I don't think Apple will pull back from deprecating and removing Manifest V2.
|
|
|
|
Quackdoc
|
2023-12-01 06:43:26
|
webkit is "relevant" to the degree it has enough userbase to keep itself going, but outside of iphone it's not really a big deal. but considering that webkit is pretty much the go to actually embedded use outside of webview stuff, it will at least manage to keep itself alive.
|
|
2023-12-01 06:44:13
|
that being said, I have seen a migration towards chrome for stuff like that too now, even xbox uses edge now instead of webkit iirc
|
|
|
|
HCrikki
|
|
Cacodemon345
The point being that the vast majority of smartphone users around the world are Android users, and therefore, won't be enjoying JPEG XL support, which means that it's pointless for websites to support it even.
|
|
2023-12-01 09:37:42
|
websites with native apps could serve regular jpeg to browser users and jxl to their mobile apps for lower bandwidth consumption and faster loading
|
|
2023-12-01 09:38:22
|
browsers could just load reconstructed jxls as jpegs
|
|
|
|
VEG
|
|
Quackdoc
I mean hell, some people still use IE and firefox for petes sake
|
|
2023-12-01 09:39:15
|
Firefox is a modern browser and it is quite popular among geeks. It's very different from obsolete IE.
|
|
|
|
HCrikki
|
2023-12-01 09:40:30
|
ads too would load faster and consume less bandwidth wether served from a publisher or selfhosted
|
|
|
|
Quackdoc
|
|
VEG
Firefox is a modern browser and it is quite popular among geeks. It's very different from obsolete IE.
|
|
2023-12-01 09:45:35
|
Firefox may be a modern browser, but it's still a very broken one. There are still quite a bit of websites that just don't render properly and break in a weird variety of ways. And yes, some apps do pull a Google and purposely do it, but no, there are actual websites that do break on Firefox, but not Chrome. Firefox is very much not the same browser it once was.
|
|
|
|
VEG
|
2023-12-01 09:46:47
|
Well, those websites are broken not because of Firefox, but because of lazy web developers that code just Chrome-only websites. The same kind of web devs that did IE-only websites in the past.
|
|
|
|
Demiurge
|
2023-12-01 09:48:22
|
Firefox is not what it used to be
|
|
2023-12-01 09:48:58
|
mozilla is dead
|
|
|
|
VEG
|
2023-12-01 09:49:09
|
Well, it was an alternative for IE monopoly. Now it's an alternative to Chrome monopoly.
|
|
|
|
Quackdoc
|
2023-12-01 09:49:24
|
Firefox has to take a degree of responsibility though. It's not as if Firefox is doing a particularly good job at trying to keep its user base. If they had done a decent job at keeping its user base, then people would still be testing for Firefox.
|
|
|
|
VEG
|
2023-12-01 09:49:45
|
Firefox had issues with IE-only websites too. The same kind of issues you may encounter today on Chrome-only websites.
|
|
|
|
Quackdoc
|
2023-12-01 09:50:04
|
I don't think it's website developers job to develop for Firefox if Firefox isn't going to make it worth developing for.
|
|
|
|
Demiurge
|
2023-12-01 09:50:18
|
mozilla cut almost all of their workforce working on firefox
|
|
2023-12-01 09:50:41
|
and cancelled all of the projects (like servo and quantum) to improve firefox
|
|
2023-12-01 09:50:52
|
They don't care about firefox at all anymore
|
|
|
|
VEG
|
2023-12-01 09:50:59
|
Servo wasn't ever planned to be part of Firefox.
|
|
2023-12-01 09:51:05
|
And modern Firefox is Quantum.
|
|
|
|
Demiurge
|
2023-12-01 09:51:37
|
It was planned to be incrementally added to firefox, that's what quantum was, slowly introducing servo code into firefox to incrementally replace gecko
|
|
|
|
VEG
|
2023-12-01 09:51:55
|
And the fact that it keeps up with an army that develops Chromium tells that a lot of people work on Firefox
|
|
|
|
Demiurge
|
2023-12-01 09:52:13
|
A skeleton crew
|
|
|
|
VEG
|
2023-12-01 09:52:25
|
Servo always was an experimental project that is still experimental and extremely unstable
|
|
2023-12-01 09:52:37
|
It was just waste of money
|
|
|
|
Quackdoc
|
|
VEG
Servo wasn't ever planned to be part of Firefox.
|
|
2023-12-01 09:53:10
|
Servo was planned for being embedded browser in, though.
|
|
|
|
VEG
|
2023-12-01 09:53:16
|
Mozilla is not a company of Google size to waste money on side projects like Servo without any potential outcome in a decade
|
|
|
|
Demiurge
|
2023-12-01 09:54:21
|
Sorry, but mozilla literally fired almost all of their developers and stopped working on firefox. it has nothing to do with servo not being good enough. Servo benchmarks were already ridiculously better than webkit/chrome
|
|
2023-12-01 09:54:49
|
Maybe you think mozilla can't possibly be evil or do something wrong, but your god is dead
|
|
|
|
Quackdoc
|
|
VEG
Mozilla is not a company of Google size to waste money on side projects like Servo without any potential outcome in a decade
|
|
2023-12-01 09:54:51
|
mozilla makes more then enough money lmao
|
|
2023-12-01 09:55:25
|
Mozilla non profit and two for profits have over a billion dollars in assets as of I think it was 2022
|
|
|
|
VEG
|
2023-12-01 09:55:39
|
Facepalm. Did you ever try Servo? It's unstable, crashes as soon as you press a button (literally), and it is not able to render properly any web page even from 10 years ago.
|
|
2023-12-01 09:55:54
|
I was enthusiastic about Servo, I was testing it for years
|
|
|
|
Demiurge
|
2023-12-01 09:55:56
|
It has nothing to do with it being a waste and everything to do with mozilla deciding to raise the executive salaries while cutting their workforce of developers
|
|
|
|
VEG
|
2023-12-01 09:56:05
|
All the years of development it was just a piece of unstable shit
|
|
|
|
Quackdoc
|
|
VEG
Facepalm. Did you ever try Servo? It's unstable, crashes as soon as you press a button (literally), and it is not able to render properly any web page even from 10 years ago.
|
|
2023-12-01 09:56:39
|
this is not true, in fact, on the old layout engine, you can even use the most popular erotica video website in the world
|
|
|
|
Demiurge
|
2023-12-01 09:56:40
|
That was after they fired everyone working on the project and the code lied dormant for years.
|
|
|
|
VEG
|
2023-12-01 09:57:03
|
That was when it was in active development
|
|
|
|
Quackdoc
|
2023-12-01 09:57:24
|
at the time, servo, while still very incomplete was somewhat usable, and for what was there, extremely fast
|
|
|
|
Demiurge
|
2023-12-01 09:57:37
|
the executives literally raised their own salaries while firing almost all of their programmers
|
|
|
|
VEG
|
2023-12-01 09:57:38
|
And again, Firefox is keeping up with Chrome. If "all the developers" were fired, they would become obsolete quickly. Or had to move to Blink.
|
|
|
|
Quackdoc
|
2023-12-01 09:57:40
|
this is why igalia devs are now being payed to work on servo, and compatibility is increasing every other daay
|
|
|
VEG
And again, Firefox is keeping up with Chrome. If "all the developers" were fired, they would become obsolete quickly. Or had to move to Blink.
|
|
2023-12-01 09:57:55
|
firefox is barely being kept afloat
|
|
|
|
VEG
|
2023-12-01 09:57:57
|
But no, they continue to develop Gecko (or Quantum if you like marketing names more).
|
|
|
|
Demiurge
|
2023-12-01 09:57:58
|
It was basically 100 times faster than chrome
|
|
|
|
Quackdoc
|
|
Demiurge
It was basically 100 times faster than chrome
|
|
2023-12-01 09:58:30
|
servo is still pretty fast for what it is, it's not near as fast as chrome, but its an old engine, and webrender still sucks
|
|
|
|
VEG
|
2023-12-01 09:58:32
|
> It was basically 100 times faster than chrome
It's an obvious lie.
|
|
|
|
Quackdoc
|
|
VEG
> It was basically 100 times faster than chrome
It's an obvious lie.
|
|
2023-12-01 09:59:00
|
exageration yes, but it was significantly faster
|
|
2023-12-01 09:59:17
|
keep in mind chrome nor firefox had very much in the way of threading, but servo was nearly entirely threaded
|
|
|
|
Demiurge
|
2023-12-01 09:59:34
|
They aren't keeping up with chrome or safari or any other browser at all. firefox and also chrome are both essentially sitting on their laurels right now
|
|
|
|
Quackdoc
|
2023-12-01 09:59:35
|
now chrome and firefox do now have a degree of threading, but not as much as servo can have
|
|
|
|
VEG
|
2023-12-01 09:59:58
|
Servo never was in any usable state ever. It couldn't be faster because it was never in working state.
|
|
|
|
Demiurge
|
|
Quackdoc
exageration yes, but it was significantly faster
|
|
2023-12-01 10:00:08
|
It was ludicrously faster.
|
|
2023-12-01 10:00:25
|
Servo was so much faster, it was at the level of ludicrousness.
|
|
|
|
VEG
|
2023-12-01 10:00:40
|
Maybe in your dreams 🙂
|
|
|
|
Quackdoc
|
|
VEG
Servo never was in any usable state ever. It couldn't be faster because it was never in working state.
|
|
2023-12-01 10:00:46
|
lies. again, I was able to browse multiple websites, and in fact, even used it for quite a while
|
|
2023-12-01 10:00:54
|
it was broken a lot sure
|
|