[Development] High-DPI 5.6 beta update

[Corentin Jabot]

Having stumbled upon this issue very recently, here are my 2 cents.

   - Svg images should be devicePixelRatio aware without having to set a
   source size
   - Likewise, QQuickImageProvider should know about devicePixelRation,
   without having to set a source size.
   - I would absolutely love an icon format, but I'm not a fan
   of QTBUG-49820 proposal. As mentioned, it basically requires a full scan of
   the directory. The performance implications are quite scary. I see a few
   solutions:
      - Use a list of files ( sources : [f1, f2, f3] ) or a list of sizes
      - Use some sort of pattern string  : source : "foo-{32x32,64x64}.png"
      (with @x detected automatically )
      - Accept .ico/icns files. The limitation is that these formats do not
      distinguish size and density (I quite like the idea of these too things
      being independent, but I don't think it will be used that often)
      - Use some sort of icon-descriptor file. But this solution feels a
      bit cumbersome
      - In any case, I feel that the extension should always be specified.
      ( source = "path/to/foo" really does feel TOO magical )


If we are only speaking about size/density (and not other features of QIcon
like modes and states), I think extending the Image item would be more
beneficial than adding a new type.


2015-12-16 11:29 GMT+01:00 Sorvig Morten <Morten.Sorvig at theqtcompany.com>:

>
> > On 15 Dec 2015, at 20:25, rpzrpzrpz at gmail.com wrote:
> >
> > Instead of worrying about @2x and @3x and trying to generate artwork in
> all of the sizes, would it not be advantageous
> > to only use SVG vector format and allow the svg plugin to generate and
> scale at run-time a single svg file in the QRC file instead of having to
> pre-generate files.
> >
> > Your thoughts on projects that use ONLY SVG image resources and not
> PNG/JPEG?
>
> I think using SVG only is fine if that works for your project, and we want
> to support it.
>
> But Qt _enforcing_ SVG only? We can’t really make that decision for our
> users.
>
> Morten
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151218/b7e95d1a/attachment.html>