You're dealing with filters, transparencies, hand-drawn paths, masking, linked files, embedded files — there's a wide realm of potential data and complexity.

If you want to test the mettle of a computer, try opening a large Photoshop file and doing anything in it.

People who use Photoshop regularly totally understand the validity of that quick demo.

This, right here, is why it's an indictment of the software industry. It SHOULDN'T be impressive that Photoshop doesn't lag. When she said that line, the entire audience should have shrugged and said to themselves "Of course you can zoom into an image in Photoshop. It's 2018. What's the big deal?"

We're also talking about multi-gig files. Outside of media the occurrence of an individual application file this large is pretty small. It's not like you can reliably play a 4K video file on many entry-level machines either.

In a similar vein, I would argue that it's a better indictment of the industry that I sometimes have to close Chrome because it's hogging more resources than Photoshop.

I realize I'm biased, but on such a machine, the observed performance is anything but rudimentary.

Tiled zooming into arbitrarily large images is otherwise rather easy to do. Go plop the largest image you can find onto your nearest Android phone and it'll zoom & pan that image at 60fps with nary a stutter or issue. It will take a while for it to re-snap the sharpness as you zoom in, though, but so was the iPad Pro. How fast it was re-decoding at the new scale factor & crop is the interesting question, but one which wasn't covered.

Otherwise we're just talking the same basic tech behind gigapixel viewers. Which isn't interesting or significant in the slightest, and has been used on mobile for years and years and years.

Do you have evidence backing up this claim?

> Go plop the largest image you can find onto your nearest Android phone and it'll zoom & pan that image at 60fps with nary a stutter or issue

I've never seen an Android device composite, pan, and zoom a multi-layer gigapixel image with the same performance I saw today. If you have a video you could share, I'd be interested to see it.

> It will take a while for it to re-snap the sharpness as you zoom in

To let you in a bit, Photoshop was doing the recomposition of the destination region in real-time. And it's not just a single layer that's on display there, but hundreds, composited together while the user zooms in and out on varying regions of the document.

Now I don't doubt that an image viewer specially optimized for zooming and panning huge images like this can do it at 60fps. The typical image viewer likely does not.

That's like wondering why the source + instrumented dev environment uses so much more resources than its compiled, optimized binary.

What a weird confusion to see on HN.

Or are you so naive you think that anything of significance is happening on or blocking the UI thread such that merely showing "smoothness" in any way reflects anything about the device's performance at actually doing the photoshop work?

Seriously? I think this is more confirming that the person you replied to is right. Unless there is some reason that I can think of that only using 2 cores is a good thing?

Everything else—the rendering, scaling, compositing, etc.—runs on the GPU, not the CPU, where it uses hundreds of cores. Y’know, like a 3D game.

And, like a 3D game, it’s still slow, because it’s doing something genuinely hard and your powerful GPU still isn’t powerful enough.

A cursory search brought up this link, but you should read up on threads and the difference between CPUs and GPUs:

https://macperformanceguide.com/blog/2017/20171223_2311-why-...

Multiple cores are really good at handling a lot of smaller processes. Photoshop just has a couple really heavy individual processes.

Demo was 12,000 x 12,000 pixels, 2 orders of magnitude would be pictures of 120 x 120 pixels.

We did more with Photoshop in the past than 128px icons.

120 x 120 = 1.44 * 10^4 pixels.

4 orders of magnitude. And in addition to that, the RAW sensor information from the camera has given each pixel more 'depth'. Often times, each color is 12bit (36bit per pixel). There's more to each pixel than what's displayed on the screen: its not just a JPG you're viewing.

Scrolling through a 3 GB 157-layer 12000x12000 image is not one of those times.

I'm not saying it's not hard: it is hard. Programming is hard. Making sure you're not occupying the UI thread for more than 16 milliseconds per frame is sometimes a challenge. You have to use all sorts of scary stuff like "concurrency" and "threads" and "GPUs". But it's 2018: non-laggy UI's should be the baseline everywhere, for everything.

Apples and Oranges.

My Amiga never did this because the whole user interface was interrupt driven, it wasn't possible for any of the bloated trash running to deem itself more important.

I think Steve even did a keynote demo of fluid finder window resizing during 10.2 release.

reference: https://macosx.com/threads/why-is-window-resizing-so-slow-st...

Perhaps they have a lot they can optimize but the levels of layers, masking, opacity, blending or whatever is complex.

There’s a lot to be said about reduced efficiencies with the layers of languages and abstractions we use today but I’m not sure photoshop is the best example to try and torch the whole industry.