Apple's plans for Core Image and resolution independence

Posted:
in macOS edited January 2014
Those of us who have installed the developer tools and tried out the experimental true resolution independence feature have all been wondering one thing: ultimately, how will the bitmapped icons used throughout the interface be handled? One option is simply to provide extremely high DPI bitmaps of these icons which can be scaled in real-time. Another option is to use vector images, but these are usually composed of nothing more than simplistic shapes. I propose that Apple will eventually use the second of these two options. If you follow the nightly builds of WebKit, you may know that Safari can now be compiled with SVG compatibility, which could mean Apple could start supporting SVG images as a standard for the web which would help them provide a seamless resolution independent environment. Furthermore, it has been speculated that the advanced filters Apple has been developing in Core Image could replace most of photoshop only with everything accelerated by the GPU. Perhaps Apple will soon start to implement a lot of new Core Image filters that deal with beveling and lighting and all of the other things that one would use in a graphics package to make Apple's signature lickable interface, allowing them to be used in realtime to generate the interface.

What do you guys think?



I might be crazy

Comments

  • Reply 1 of 5
    Icons in Tiger can be up to either 256x256 or 512x512 (I forgot which).



    This means that they can be the same size they are today at two or four times the resolution. Keep in mind that when resolution independence comes around, we're not going to have infinite resolutions?resolutions are still restricted by real world factors (for instance, a 200DPI LCD screen would probably cost thousands of dollars right now, and the graphics card(s) to drive it would make the machine dog slow for anything else but blitting graphics to screen.)



    So, 200 DPI screens aren't that realistic for a few years yet... the size of widgets and icons is the least problematic... er, problem.



    As for rendering widgets in real time... why? It's really simple to blit tiny tiny icons to the screen. It's fairly costly to render them in real time. For even simple effects in my app, things like adding shadows and drawing bezier paths get noticeably slow when you're dealing with lots of widgets (ie, it takes more than a few milliseconds to draw them all)... I'm going to have to change the code at some point to just blit bitmaps. Just because you "can" do some things in real time doesn't mean you'd want to.
  • Reply 2 of 5
    Well, the algorithms would have to be very heavily optimized, but who knows where hardware will take us in a few years. Regardless, you make a good point, bitmaps are so much easier to deal with, I was just dreamin' Apple's always been able to do some pretty crazy things with graphics that seemed impossible at the time. A cursor being rendered smoothly without added hardware seemed pretty crazy in the early 80s, and would you look at the circle algorithm in 1984 era QuickDraw, that thing was intense!
  • Reply 3 of 5
    wmfwmf Posts: 1,164member
    Vector icons wouldn't have to be rendered every time; they can be rendered once at each particular size and cached. GNOME is already using lots of SVG icons.



    But I think most icon designers will stick with bitmaps since it gives them the most control.
  • Reply 4 of 5
    lundylundy Posts: 4,466member
    Where can one get ahold of this SVG-enabled Safari? Thanks..
  • Reply 5 of 5
    Quote:

    Originally posted by lundy

    Where can one get ahold of this SVG-enabled Safari? Thanks..



    http://nightly.webkit.org/builds/
Sign In or Register to comment.