211–215 of 215 posts
Earlier quoted context omitted.
that video does not say anything about the home/del/pgup/pgdn buttons...? does it?
They're going back to the 6-row keyboard (top), not 7-row keyboard (bottom): http://i.imgur.com/NpmHQbL.jpg
Earlier quoted context omitted.
With every tech company trying to imitate all of Apple's poor decisions, it is getting hard to find a laptop that has physical buttons. They have all been switching over to having just the trackpad.
How is it a poor decision? OS X generally has been designed to not need right clicking. And where it does, aka Xcode you can just do control click in most places. I don't really see how this is a poor decision on apples part. For windows sure, right clicking abounds, though I'd argue that right there is the crux of the problem in general. The over reliance on right clicking in user interfaces I think isn't too far of…
Earlier quoted context omitted.
How is it a poor decision? OS X generally has been designed to not need right clicking. And where it does, aka Xcode you can just do control click in most places. I don't really see how this is a poor decision on apples part. For windows sure, right clicking abounds, though I'd argue that right there is the crux of the problem in general. The over reliance on right clicking in user interfaces I think isn't too far of…
My fundamental complaint is that Apple, as a company, prefers form over function. Avoiding right mouse clicks in the name of simplicity. Designing thin laptops instead of durable laptops. Restricting installation on iOS to just the App Store.
> Avoiding right mouse clicks in the name of simplicity
Simplicity has nothing to do with form, that is function.
> Designing thin laptops instead of durable laptops.
Thin/light laptops has nothing to do with form, that is function (who wants to carry around a brick?). And what is more durable than a MBP anyways?
> Restricting installation on iOS to just the App Store.
Security and safe experiences has nothing to do with form, that is function.
"Form" would be fashion, and Apple definitely has plenty of that, but all the points you listed don't focus on that.
Having just spent two days optimising the scrolling performance of my Mac app I understand the reasoning behind this. Fluid scrolling is hard. And while scrolling might be handled in part by the GPU, its still the CPU that renders the text that you're scrolling. If you're aiming for 60FPS, you probably have less than 10ms to render a screen when the user is scrolling quickly.
If you don't mind me asking, what optimizations are you making? I'm curious about what it takes to get 60 FPS scrolling in a Mac app.
My first step was to switch to using CoreText, a lower level API for rendering text. This reduced overheads by around 50%.
My second step was to cache layout information for recently displayed strings in a small cache. Tables often contain a lot of repeated values so this saved a lot of time; in some cases up to 70%.
After these optimizations, my own code was no longer the bottleneck. I still don't reach 60FPS on my 2009 Macbook Pro, but that was expected...
(Note: 60FPS scrolling is not a problem if your views are smallish, so that they can be entirely cached on the GPU; the problem occurs only when your views are very large and the users scrolls very fast so that the CPU can't keep up with rendering tiles for the GPU)
Earlier quoted context omitted.
If you don't mind me asking, what optimizations are you making? I'm curious about what it takes to get 60 FPS scrolling in a Mac app.
In my specific case, I'm displaying a table view with hundreds of rows and potentially dozens of columns. The bottleneck was the slow text rendering in App Kit. Text rendering is pretty fast when you render long strings, but there is a lot of overhead when rendering many short strings. My first step was to switch to using CoreText, a lower level API for rendering text. This reduced overheads by around 50%. My second…