| Important Notice: Due to repeated WikiSPAM attacks it was nessesary to change the access policy! Only registered users can now edit. |
Office/FX-602P/QVGA
From UIQ3 open-source software
Contents |
The width by height ratio of QVGA (240 × 320pixel , 1:1.3) and an FX-602P (15.2x7,6cm, 1:2.0) are quite incompatible. Just resizing an image of an FX-602P will squash the picture beyond recognition. Even if you cut way the On/Off slider and the space between the keyboard and the display one is still left with ratio of 1:1.6.
Also the FX-602P has 50 buttons. For comparison: The HP-45 and the HP-41 have 35 buttons and the HP42 has 37 (The HP41/42 use XEQ and menu/catalog system for most functions). Taking this into account it seems that just using an background featuring an scan or realistic representation of the original calculator is not an option for the FX-602P.
Display
The FX-602P got eleven 5x7-matrix characters and three 7-segment characters. To get a good result with 240 pixel width each FX-602P pixel is mapped to 3x3 QVGA pixel. 2 pixel are space are left between each character. The result looks a little like this:
With an 48 pixel height a total 272 pixel are left for the two button groups. You could squeeze the display area into 32 pixel but it would not look nice.
The boarder around the display area is made of by parts from an original FX-602P photo.
character drawing
There are two options open to draw the characters - using drawRectangle or drawImage:
- With drawImage one creates a little PNG graphic for each character which is then drawn into the display area. Note that all images are read using lazy reading.
- With drawRectangle each character is stored as hex codes (5 byte with 7 bit each). This hex codes are then decoded and each calculator pixel is then painted to the display area separately as little 3x3 rectangles.
The first option is easier to program and the second option consumes less memory. Which of the two options is faster can not be determined with out running a test program.
| Test | Timing samples (ms) | mean Timing (ms) |
|---|---|---|
drawImage first run, 200 times a 
| 672, 593 | 632.5 |
| drawImage second run, 200 times a
| 92, 78, 93, 77 | 85 |
| drawRectangle, 200 times a
| 1007, 1006, 1006, 1030 | 1012.25 |
Surprised? No need to - modern Smartphones have a Blitter on board which makes transferring an image a lot faster then writing a filled rectangle. The only surprise is perhaps how much faster the image draw is.
For general amusement here the routines used for both tests:
for (int i = 0; i < 200; i++)
{
if (Character [0] == null)
{
Character [0] =
net.sourceforge.uiq3.calculator.ui.Utils.createImage (
/* Canvas => */this,
/* File_Name => */Integer.toString (70) + ".png");
} // if
graphics.drawImage (
/* img => */Character [0],
/* x => */Character_X + i,
/* y => */Character_Y,
/* observer => */null);
} // for
final byte [] Null =
{ 0x3e, 0x51, 0x49, 0x45, 0x3e };
graphics.setColor (Display_Foreground);
for (int i = 0; i < 200; i++)
{
for (int j = 0; j < Null.length; j++)
{
final byte Col = Null [j];
for (int k = 0; k < 7; k++)
{
final byte Row = (byte) (1 << k);
if ((Col & Row) != 0)
{
graphics.fillRect (
/* x => */Character_X + i + j * 3,
/* y => */Character_Y + k * 3,
/* width => */3,
/* height => */3);
} // if
} // for
} //for
} //for
Buttons
top small buttons
The top buttons consist of 5 rows with 6 buttons each. On the QVGA display each top button is resized to 40x25 pixel so all top buttons will occupy 240x125 pixel which is a little less of half the remaining screen. The result looks a little like this:
bottom large buttons
The bottom buttons consists if 4 rows with 5 buttons each. On the QVGA display each bottom button was resized to 45x32 pixel so all bottom buttons occupy 240x128 pixel which is about as large as area occupied by the top buttons.
The remaining space is filled with lines and other eye candy.
active keyboard
To save space an active keyboard is implemented. With active is meant that when you use "inv" or "alpha" the writing on the keys itself is changed to the currently active meaning. That way no printing above and below the button is needed and the buttons can drawn closer together. Here a few screen shots of the JavaME Emulator:
While Java has Unicode support which should cover most special characters needed the installed fonts might not. There are even differences between the characters supported by the Emulator and real device.
Theme
The same Theme manager as for the the HP45 Emulator is used. However the actual file format is enhanced so the four text variations for each button can be set as well.
