femtovg area : scale by the scale factor to fill the screen #2031
Conversation
| @@ -89,8 +89,9 @@ impl GLAreaImpl for FemtoVGArea { | |||
| let canvas = canvas.as_mut().unwrap(); | |||
|
|
|||
| let area = self.obj(); | |||
| let w = area.width() as u32; | |||
| let h = area.height() as u32; | |||
| let scale_factor = self.obj().scale_factor(); | |||
There was a problem hiding this comment.
Like I said in the issue, this should really use the (fractional) scale factor of the GDK surface. That this doesn't work is either a bug in GTK or something else is wrong here.
There was a problem hiding this comment.
You wrote this change of the example so I assume it's in your interest that what you're doing here is actually correct. If that's not the case then feel free to just ignore my comment and do whatever works for you, but don't be surprised if it breaks in the future.
Whenever I asked about the very same thing in the past, I got told by GTK developers to use the fractional scale factor because it's wrong otherwise if fractional scaling is used. Apparently this is not the case here, so something is wrong. It would be good to figure out what, but I honestly don't care enough after your comment to investigate myself.
That @bilelmoussaoui and I disagree here or on some other topic is also a good indication that some more clarification is needed. Maybe one of us is right, maybe neither. That you see that as a problem is rather puzzling. The goal here is to do the right thing, not to do something that happens to work.
There was a problem hiding this comment.
Sorry for lashing out yesterday ...
For the fractional scaling part, I don't really know if something is wrong or not (I'm not totally surprised that there would still be plenty of integer scaling going on with gtk4 as not all of the fractional scaling stuff is pure fractional scaling, and will probably never truly be until gtk5).
Printing the surface size from the gl context directly, I have that the size shown in the debugger is the integer scale factor * the size given the the surface width/height method (and not multiplied by the fractional scale factor, regardless of the renderer of dmabuf status)
I will open an issue on the gtk gitlab so that this is clarified.
And yes, I won't be surprised this won't work in the future (a lot of things change or can break between major gtk 4 version) though I'm content with this working until the next big gtk 4.20 release next year (if it breaks by then maybe I'll take another look).
There was a problem hiding this comment.
First of all, for a bit of context, I only took of the maintainership of poppler-rs because no one really updates it after it was initially created by someone else. I don't use it, I don't need it and I don't use anything that depends on it. What I am doing on all the crates in World/Rust is beyond what anyone could during their free time, which is why things progress very slowly especially lately.
If you want to take over the maintainership of poppler-rs just le me know and will give it to you for free.
There was a problem hiding this comment.
@sdroege I've asked here for the original issue https://gitlab.gnome.org/GNOME/gtk/-/issues/7489#note_2413072 so it seems using the scaling factor is actually correct here, though more for historic reasons.
I reckon more recent developments (dma-buf) use the fractional scaling instead.
Maybe that will change with an ulterior gtk4 (or 5 ?) version though (but that would be a breaking change + we can deal with it when the time comes).
@bilelmoussaoui I'm verry verry sorry for the messages (I think they deserve to be deleted). I'll try to do something constructive now (instead of inexcusable verbal abuse) and send more PR your way for poppler-rs and generally get more involved in the project.
There may be other users interested in becoming contributors/maintainers, though no certainty here.
I can't really say "let me take maintainership" now, cause that would probably leave a bad taste and I don't want that. I'd rather we have regular contributors/contributions (others or me) first before maintainer status can be discussed. It's true as well that there wasn't that much activity on the repo, I was pretty surprised to open the first ever issue on the gitlab, so that's unfair to fault you on that.
(I understand that maintaining something that you don't need/use means that it'll not be where you'll spend most of your time, and it might be less fun compared to spending time on something you really care about. Hence the need for users turned contributors imo)
fixes #2015