View Single Post
  #8  
Old 2012-10-28, 15:49
jkheal jkheal is offline
 
Join Date: Jul 2008
Posts: 1,576
I've thought about this a little more, and I am quite certain that providing larger device images is not a trivial exercise. First of all, I'll assume that the intention to depict devices with bitmaps would continue so as to maintain the design aesthetic.

So now we have the issue of rendering a bitmap sharply at different sizes. For this, a "maximum" size would have to be assumed. Now, are you going to provide the user, say, two or three different sizes to choose from, or are you going to allow the user to adjust the size of the devices continuously within a given range? The former would be easier on the coding end, I suppose, but let's say you wanted to allow the user to adjust the size of the devices dynamically. If so, now you're going to have to call graphics methods to resize and re-anti-alias things. This may be fairly trivial for the device backgrounds. But, you'd have to do this for the controls that move, too. Typically, a knob on a device might consist of maybe 60 or 80 individual images to render it at it's various positions. As you whipped up and down with the mouse to furiously rotate a knob, now not only would Reason have to switch out the images to render the position change, but it also have to — with each image change — resize and resample the "master" images in the process.

For a test, I just watched the Task Manager while I resized a small image in Photoshop. The Task Manager reported about 15-30 CPU utilization during the resize. I could imagine the knob-turning-image-resizing scenario above literally pegging the CPU.

All this to say that I think "bigger" devices is a bit more complex than two or three weeks of the UI guy or gal's time.
__________________
Jon Heal
---
Reason 7.0.1 • A computer • A few boxes that do something or other • Virtually no talent and/or skill

Ye Olde FishCAM

Last edited by jkheal; 2012-10-28 at 16:55.