Announcement

Collapse
No announcement yet.

X.Org Could Use More Help Improving & Addressing Its Security

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • tildearrow
    replied
    Originally posted by billyswong View Post
    oiaohm Thanks for information supplementation! First, let's see what is the set buffer scale API doing:
    Code:
    void wl_surface_set_buffer_scale
    (
    wl_surface* wl_surface_
    int scale
    )
    It is explicitly forbidding native fractional scaling by the wonderful int scale .

    Second, let's see what those developers talking in the mailing list archive you linked to:

    The developers are in effect saying: I like the Mac way so I forbid the Windows way. Because this way of scaling is easy to me. Screw you Hahaha.
    Also "one surface spanning several non-identical monitors" is "not worth caring about".
    I am one month late, but here I propose: Compatible Fractional Scaling!

    Since nobody would ever scale by more than 255x, let's change int scale to float scale and read the value.
    If the raw value of scale is between 00000000 and 000000FF, treat it as integer scale.
    Otherwise treat it as floating point scale.
    This partially keeps compatibility with old code since int and float have the same size (4 bytes).

    The only problem is that old implementations may treat 1.5x as 1069547520x (3FC00000), which would most likely trigger a crash.
    Last edited by tildearrow; 16 October 2021, 04:59 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by blacknova View Post
    It have been 8 years already and scale is still integer. And I don't think fraction scaling currently available can be enabled in multi-monitor configurations anyway.

    I still think that it would have been better to stick to real world sizes for UI design and let underlying system handle correct rendering using actual output's DPI.
    That the thing fraction scaling is not easy todo right.
    https://libredd.it/r/linux/comments/...nda_sucks_ngl/

    The most common Wayland fractional scaling exploits the means to request buffers of different interger scales. Interger scaled above the targeted fraction scaling valve.

    Yes there is a method when interger scaling was added to the protocol in 2013 to produce fractional scaling that was documented it does produce good looking results but its not without its problems. The method is very heavy on memory when you are outputing like 1.25 you have a buffer at 1.25 in the compositor rendered by the compositor and buffer at 2x from the application. Interesting problem here why Xwayland looks so crap your compositor ask Xwayland for 2x buffer and it goes screw you I am only giving you a 1x buffer then most wayland compositor upscales the 2x buffer(by really basic method that 1 pixel just comes 4) then down to 1.25 and does not look too good. Yes scaling formulae most wayland compositor that support fractional scaling are using is good at down-scaling not up-scaling there are exceptions like valve gamescope that formulae is good at upscaling not so hot at downscaling.

    Sway and most wlroots based does in fact support enabling fractional scaling in multi-monitor setups. Remember higher memory usage and extra processing using these modes it not going to be fun all the time.

    Wayland protocol being extended to support non integer scaling does offer to reduce the memory usage and cpu overhead when/if toolkits support it.

    Fractional scaling is not exactly a fun or simple problem. Particular with the issues with scaling formule normally only been good in one direction if they are good in any direction.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by pal666 View Post
    You done yet or do you want to go back to 4chan?

    Leave a comment:


  • pal666
    replied
    Originally posted by mdedetrich View Post
    Right back at you pal (pun intended) as is evidenced by your latest comments.
    you are perfect example of https://en.wikipedia.org/wiki/Dunnin...3Kruger_effect

    Leave a comment:


  • kreijack
    replied
    Originally posted by mppix View Post

    I don't think I understand what you mean by cooperate. The compositor still manages windows.. and for example on gnome, windows "cooperate" fairly well (split scree etc).
    I was a bit cryptic :-)
    For example the title bar has a set of button which allow the user to set the window behavior: e.g. some WM, have the "sticky" button, that prevent the window to go below in the windows stack....


    Originally posted by mppix View Post
    Again, I don't think I understand what you mean here. "Raise on click on the title bar" is pretty much how every DE works...
    Not really. In general the window is raised when it receive a click in any part of the window. The behavior describe above is when the window is raised only when it receive a click on the title bar.

    I like this behavior so I can put a window below in the stack, but leaving a button visible; so I still be able to push it without changing the windows stack.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by pal666 View Post
    they never insisted on that. only people who know exactly zero about software development could think this way. they insisted on "it's not their job". everyone is free to develop library and share it with others who have similar requirements
    Yes, of course. But in practice either you provide something official or fragmentation ensues, so insisting on it not being their job is not very different :shrug:

    Originally posted by pal666 View Post
    no, your others are part of xorg project. it's like "in practice gnome users are expected to run mutter full time". xorg is one x11 implementation, there are many others unrelated to it. though it's dominant one(just like gnome btw)
    I stand by my word. I’m aware all others are now part of the X.org project, someone else said that already. Yet again, for the matter of fragmentation those others don’t matter, because nobody uses them. Compare to all major DEs with actual real users and actual real maintainers (who can't use their time twice to also look at others' implementations) rolling their own.

    Originally posted by pal666 View Post
    not providing pieces for implementing print server? why do you think such nonsense? wayland has to provide only important things and important for everyone - not every wayland compositor is a desktop, wayland runs on smartphones and other devices. desktops should provide desktop-specific parts(jointly if they wish)
    Of course nobody is asking for the damn print server, but more than that, I didn’t say _Wayland_ had to provide it, but the replacement for X11 needs to be an ecosystem equally capable of performing the common workloads. That means if you want a display protocol to succeed, you need to make sure there will be a different protocol for whatever else that falls out of its scope, separate from it but in existence. Otherwise people will still rely on X11.
    That’s what “all the pieces” mean. It’s still independent pieces, building blocks, but with the potential to replace X11 without everybody solving the same problem again and again because the replacement replaces only the most basic elements.

    Originally posted by birdie View Post

    What you're hinting at requires a graphical toolkit which works closely with the graphical system and we have none. Every other successful OS out there has a toolkit closely coupled with its window system/GUI which Linux adepts don't accept. Actually Xorg has a low level graphical toolkit because X11 provided one but Wayland threw that idea away.
    But TBF, Wayland threw that idea away because none of the major toolkits were using them. I wouldn’t blame someone not wanting to maintain something their users (which in practice end up being those toolkits, mostly) don’t seem to care about.

    Originally posted by blacknova View Post

    Fixing it would require to introduce single drawing toolkit, I don't see that, people will argue on it for longer than they implement Wayland.
    That doesn't mean it isn't the right approach, it only means we're so damn interested in bikeshedding we prefer a fragmented and incomplete ecosystem over any level of compromise. Fun thing is we're compromising on having something that is functional.

    Leave a comment:


  • birdie
    replied
    Originally posted by blacknova View Post

    Fixing it would require to introduce single drawing toolkit, I don't see that, people will argue on it for longer than they implement Wayland.
    I'm 10,000% for it. This will simplify and improve all the existing Wayland toolkits momentarily and again shave off tens of thousands of duplicated lines of code.

    Leave a comment:


  • blacknova
    replied
    Originally posted by birdie View Post

    Are you saying each Linux toolkit and graphical application (not using any toolkits) should reimplement this feature over and over again? This sounds stupid as hell and again no other OS works this way - they all have some ground-level toolkit which does that automatically, even 25 years old Win32 for Christ's sake.
    Fixing it would require to introduce single drawing toolkit, I don't see that, people will argue on it for longer than they implement Wayland.

    Leave a comment:


  • blacknova
    replied
    Originally posted by oiaohm View Post
    Yes it might only be int scale in 2013. Except this means what was built into the wayland protocol include multi buffer support.

    https://gitlab.freedesktop.org/wayla...7#note_1013202s
    Yes a party is working on extending that system to have fractal scaling with a functional implementation in Weston.
    It have been 8 years already and scale is still integer. And I don't think fraction scaling currently available can be enabled in multi-monitor configurations anyway.

    I still think that it would have been better to stick to real world sizes for UI design and let underlying system handle correct rendering using actual output's DPI.

    Leave a comment:


  • birdie
    replied
    Originally posted by billyswong View Post
    What's important is to allow applications to do the scaling / tonemapping themselves for mixed monitors.
    Are you saying each Linux toolkit and graphical application (not using any toolkits) should reimplement this feature over and over again? This sounds stupid as hell and again no other OS works this way - they all have some ground-level toolkit which does that automatically, even 25 years old Win32 for Christ's sake.

    Leave a comment:

Working...
X