From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] Thoughts on Wayland?
Date: Wed, 7 Aug 2024 13:47:39 +0200 [thread overview]
Message-ID: <CAFSF3XPx__3Y-ZshUK1LTPV=S3E3G4QsrtP3eW4+b5=RGQeqdA@mail.gmail.com> (raw)
In-Reply-To: <A657E437-17CE-4E56-8731-0362E9495C18@quintile.net>
> However if you resize the resulting image, e.g. using a scaling monitor,
> or resizing a screen-grab the result will most probably look vile; covered
> in extra fringes or echos around letters (spacial alias)
It will still look like vile whether you antialiased once at the
beginning or not. Because every time you resample you have to do it
again.
And it only gets worse each time.
Personally I found I have to turn off scaling in my monitor and use
it's native resolution, anything else is unusable.
If displayport cables had infinite bandwidth, i'd be like you and
render everything at a *higher* than native resolution and make the
monitor downsample. that would also be the day i start using
antialiasing even on fonts and start scaling each viewport
(separately) up and down as I please.
Sadly that is not possible, so I'm saving bandwidth which happens to
also increase link reliability: i continue to let my gpu output my
monitor's native resolution. it's a good sweet spot.
The goal should always be to avoid resampling, or to only downsample
once, with Lanczos, as near to the monitor as possible.
Sadly this means we have to render at the correct DPI already on the
application layer, and demand that nothing else afterwards resamples
our outputs. This makes the application more complicated. But I see no
valid way around it.
And don't think I don't regret the many downsides: For example, on the
UI side what also would help is to make it easy to snap back to the
original resolution and make it easy to pan the image with a very low
end-user delay.
Hard with the current designs, you'd need to first make your own
devdraw scaling monitor for this, and then offload zooming from page
(our image/pdf viewer) into devdraw itself. that's a slippery slope
though, cause next you'll ask for html and pdf rendering inside
devdraw, else you'd have to render at a very high and wasteful
resolution bec. for quality results you want to only downsample, never
upsample. Harder to find the sweet spot here, but I'm sure there's
one, if you care enough ;)
with modern systems the assumption seems to be that everything needs
to be resampled 5 times. the result hurts my brain. And they still
require GPUs for the other parts of the programs regardless, they are
just not used for anything useful but animations, video codecs,
website ads with crypto-miners, and 3D games.
If we can make a devdraw scaling monitor, it should support Lanczos
resampling which includes anti-aliasing, and support for common lossy
image codecs (instead of lz77). Then we can avoid the worst-case
scenario where we decode a lossy image and then upsample it to various
wasteful resolutions as we keep zooming in, which only gets slower and
slower at each iteration, infuriating the user. Tried zooming in on a
screenshare in a modern mainstream app? It also feels like that.
about interlacing: thankfully that's not a common VGA mode.
bec. all modern software sucks, my favourite resolution remains
1600x1200 and 60Hz is enough for my light mousing around. i never need
to upsample cause of my superior low resolution. and i'm quite sure
that my eyesight will degrade faster than software development efforts
are bearing fruits.
next prev parent reply other threads:[~2024-08-07 11:49 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-04 19:26 Willow Liquorice
2024-08-04 19:44 ` Stuart Morrow
2024-08-04 19:49 ` Willow Liquorice
2024-08-04 19:54 ` Eli Cohen
2024-08-04 19:59 ` Eli Cohen
2024-08-04 20:04 ` Eli Cohen
2024-08-04 20:05 ` Eli Cohen
2024-08-04 20:09 ` Willow Liquorice
2024-08-04 20:29 ` Eli Cohen
2024-08-04 21:23 ` ori
2024-08-04 21:43 ` ori
2024-08-04 22:00 ` David Leimbach
2024-08-04 22:22 ` ori
2024-08-04 22:42 ` David Leimbach
2024-08-04 22:57 ` ori
2024-08-04 21:10 ` Willow Liquorice
2024-08-04 21:24 ` ori
2024-08-04 21:25 ` Eli Cohen
2024-08-05 8:13 ` Willow Liquorice
2024-08-05 8:29 ` ori
2024-08-05 8:52 ` sirjofri
2024-08-05 8:57 ` Noam Preil
2024-08-05 9:12 ` sirjofri
2024-08-05 11:51 ` hiro
2024-08-05 9:03 ` Willow Liquorice
2024-08-05 11:05 ` Shawn Rutledge
2024-08-05 12:01 ` hiro
2024-08-05 12:26 ` sirjofri
2024-08-05 11:15 ` David Arnold
2024-08-05 11:47 ` hiro
2024-08-05 12:35 ` sirjofri
2024-08-04 20:01 ` Willow Liquorice
2024-08-04 21:23 ` sirjofri
2024-08-04 20:08 ` mkf9
2024-08-04 20:35 ` Willow Liquorice
2024-08-04 20:32 ` Pavel Renev
2024-08-04 21:31 ` ori
2024-08-05 6:09 ` Noam Preil
2024-08-05 8:02 ` hiro
2024-08-05 11:51 ` Shawn Rutledge
2024-08-06 16:37 ` hiro
2024-08-06 17:57 ` sirjofri
2024-08-07 9:27 ` Steve simon
2024-08-07 11:47 ` hiro [this message]
2024-08-05 12:54 ` Willow Liquorice
2024-08-05 13:13 ` [9front] Fortune worthy Steve simon
2024-08-05 20:06 ` [9front] Thoughts on Wayland? Jon Sharp
2024-08-06 0:07 ` Eli Cohen
2024-08-06 0:09 ` Eli Cohen
2024-08-06 1:57 ` Michael Misch
2024-08-06 13:01 ` Emil Tomczyk
2024-08-04 22:27 ` Dave MacFarlane
2024-08-05 6:10 ` Noam Preil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFSF3XPx__3Y-ZshUK1LTPV=S3E3G4QsrtP3eW4+b5=RGQeqdA@mail.gmail.com' \
--to=23hiro@gmail.com \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).