Widget to device pixel alignment under fractional DPI scaling

Alvin Wong alvinhochun at gmail.com
Mon Oct 29 10:15:54 GMT 2018


Hi Dmitry,

If this is the case, shouldn't it be better to change the behaviour of
Krita to match that of Qt, i.e. use qFloor for the conversion instead
of qCeil? The code in Qt would have been doing it this way for quite a
while, and asking Qt to change this behaviour could possibly break
other existing Qt applications.

Best Regards,
Alvin

Dmitry Kazakov <dimula73 at gmail.com> 於 2018年10月18日週四 下午6:43寫道:
>
> Hi, Alvin!
>
> I didn't test Krita much on fractional scaling, but I haven't seen any
> special code in Qt for this alignment. We have a thing like that is
> Krita to support Instant Preview, but it has nothing related to GUI.
> > 3. On QOpenGLWidget: It creates the FBO in device pixels in
> > `QOpenGLWidgetPrivate::recreateFbo`, but with the code `const QSize
> > deviceSize = q->size() * q->devicePixelRatioF();` the FBO size is
> > implicitly truncated to integer.
> Yes, it looks like truncation is possible here. First, Qt calculates the
> desired size of the widget in DI-pixels, and then allocates a
> framebuffer of a corresponding size. When we do a thing like that in
> Krita, we usually use qCeil() for the final size. But in Qt's code,
> there seem to be no such thing.
>
> I guess the best approach would be if you provided us with a patch that
> we can apply to a local build of Qt in Krita. And after testing by the
> users it would be much easier to push it upstream to Qt :)
>
> >   Is there a possibility of
> > rounding errors, especially when the QOpenGLWidget is not using its
> > own native window?
> I guess there should be some rounding errors, yes. Usually, such errors
> look like semi-transparent or write line at the border of the canvas.
>
> --
> Dmitry Kazakov
>


More information about the kimageshop mailing list