4 ms·

Shame that you specify pixels in the function calls themselves. If it were really abstracted, it would have an arbitrary 'size unit' which the glue code could

by stonogo 11y ago

Shame that you specify pixels in the function calls themselves. If it were really abstracted, it would have an arbitrary 'size unit' which the glue code could translate on the backend. In a world where one user has a 1366x768 screen and her neighbor has a 4k display, we need to move past interface code specifying pixel sizes up front, both on the web and off.

vurtun 11y ago
There are two different versions. The first one uses pixel measurements like you said the other one uses a fractions of the window. If it is something requested then it is something that can be changed quite easily either by me if the feature is requested or the user since it only requires modifying one function. Furthermore for input you only provide your input data the library does not control it and the output can be scaled if required.
CamperBob2 11y ago
Do you want Qt? Because this is how you end up with Qt. (I'm mostly kidding but in my experience, the sorts of apps that you build with this sort of library invariably end up dealing with pixels anyway. There's no religious reason why resolution-independent scaling code has to live in the UI primitive library, especially since it probably can't be confined there.)
unexistance 11y ago
I always have an idea in my mind that we should scale / show the interface based on font-size, adjusting borders / button accordingly p/s: obviously I have NO idea how easy / complex this would be, just an idea given that sometimes text contained in an element bleeds / overflows / outright missing
- ktRolster 11y ago
  Problem is, we still have jpgs. As long as we have raster images (instead of vector images), we'll be laying some things out based on pixels. And as long as we have photographs, we're going to have raster images, for the foreseeable future.
  - adrianN 11y ago
    Rasterizing vector images to different sizes without getting blurry results is not trivial.
    - iso-8859-1 11y ago
      If all targets have a relatively high DPI, does that still hold? Wouldn't it be more correct to say "it isn't trivial to rasterize vector images for low-DPI displays?"
  - oneeyedpigeon 11y ago
    Why not have the interface scale the image to the required size, as HTML/CSS can do?
- m_eiman 11y ago
  That takes you towards HTML- or XAML-style UI definitions. I'm doing something like this in my (experimental) layout lib for embedded devices. I've written a bit about it: https://www.eiman.tv/blog/posts/liblayout/index.html https://www.eiman.tv/blog/posts/liblayout/index.html
jws 11y ago
I find that pixels are appropriate at both the "small code" end and the "perfect display" end of user interface rendering. In between the "I have lots of CPU but I can't afford the mental time to get this perfect" is served well by abstract units. The problem that hits abstract units is that for features which are small, you never really know how big they will be. It's easy to end up with elements which should look similar but some are three pixels wide and some are four, or the spacing is a little ragged from the rounding. Some kits avoid this by just antialiasing everything. Then you try to draw a detailed graph or a musical score and some of your horizontal lines are sharp and crisp because they hit solidly inside a pixel, and some are a grey smear because they hit a crack. This is probably a large reason why many graphs and charts you see on the web look like they were drawn by a child with a felt tip marker. A 3 pixel wide line is pretty forgiving about where it falls.
panic 11y ago
Graphics on a 1366x768 display end up looking like mush if they're not aligned to pixels. Once everything's higher-res this will be less of an issue, though.

by stonogo 11y ago

vurtun 11y ago

There are two different versions. The first one uses pixel measurements like you said the other one uses a fractions of the window. If it is something requested then it is something that can be changed quite easily either by me if the feature is requested or the user since it only requires modifying one function. Furthermore for input you only provide your input data the library does not control it and the output can be scaled if required.

CamperBob2 11y ago

Do you want Qt? Because this is how you end up with Qt. (I'm mostly kidding but in my experience, the sorts of apps that you build with this sort of library invariably end up dealing with pixels anyway. There's no religious reason why resolution-independent scaling code has to live in the UI primitive library, especially since it probably can't be confined there.)

unexistance 11y ago

I always have an idea in my mind that we should scale / show the interface based on font-size, adjusting borders / button accordingly p/s: obviously I have NO idea how easy / complex this would be, just an idea given that sometimes text contained in an element bleeds / overflows / outright missing

ktRolster 11y ago
Problem is, we still have jpgs. As long as we have raster images (instead of vector images), we'll be laying some things out based on pixels. And as long as we have photographs, we're going to have raster images, for the foreseeable future.
- adrianN 11y ago
  Rasterizing vector images to different sizes without getting blurry results is not trivial.
  - iso-8859-1 11y ago
    If all targets have a relatively high DPI, does that still hold? Wouldn't it be more correct to say "it isn't trivial to rasterize vector images for low-DPI displays?"
- oneeyedpigeon 11y ago
  Why not have the interface scale the image to the required size, as HTML/CSS can do?
m_eiman 11y ago
That takes you towards HTML- or XAML-style UI definitions. I'm doing something like this in my (experimental) layout lib for embedded devices. I've written a bit about it: https://www.eiman.tv/blog/posts/liblayout/index.html https://www.eiman.tv/blog/posts/liblayout/index.html

jws 11y ago

I find that pixels are appropriate at both the "small code" end and the "perfect display" end of user interface rendering. In between the "I have lots of CPU but I can't afford the mental time to get this perfect" is served well by abstract units. The problem that hits abstract units is that for features which are small, you never really know how big they will be. It's easy to end up with elements which should look similar but some are three pixels wide and some are four, or the spacing is a little ragged from the rounding. Some kits avoid this by just antialiasing everything. Then you try to draw a detailed graph or a musical score and some of your horizontal lines are sharp and crisp because they hit solidly inside a pixel, and some are a grey smear because they hit a crack. This is probably a large reason why many graphs and charts you see on the web look like they were drawn by a child with a felt tip marker. A 3 pixel wide line is pretty forgiving about where it falls.

panic 11y ago

Graphics on a 1366x768 display end up looking like mush if they're not aligned to pixels. Once everything's higher-res this will be less of an issue, though.