Thread: [Waba-spec] Proposed Vm.java and Resource.java
Status: Abandoned
Brought to you by:
bornet
From: Sean L. <se...@cs...> - 2001-12-03 19:52:39
Attachments:
Vm.java
Resource.java
|
After looking at Waba's and SuperWaba's Vm implementations, and knowing that implementation of the Class class will take longer than expected, allow me to make the following recommendation for a new Vm class: |
From: Guilherme C. H. <gu...@us...> - 2001-12-03 21:24:38
|
I'm changing today the Vm class. Here are the changes: ! removed some methods from class Vm and putted as constants in class Settings. Below is the convertion table: . Vm.oldStyle==true -> Settings.uiStyle == Settings.PalmOS . Vm.oldStyle==false -> Settings.uiStyle == Settings.WinCE . Vm.getScreenSize -> Settings.screenWidth,Settings.screenHeight . Vm.isColor -> Settings.isColor . Vm.getMaxColors -> Settings.maxColors . Vm.getUserName -> Settings.userName . Vm.getPlatform -> Settings.platform Sean, thanks for your complains. guich |
From: Sean L. <se...@cs...> - 2001-12-04 16:01:44
|
Guilherme, I defined getMaxColors as follows in Vm.java: /** Returns the number of colors supported by the device. * Colors are defined as follows: * 0 means 2^32 colors. * 1 indicates a lookup table of colors or other custom coloring, * which will be defined later * -1 is reserved for future use. * 2 means black and white. * Other values <= 16 mean that the device only supports gray scale * with that number of grays. * Negative values N also mean that the device only supports gray scale * with AbsoluteValue(N) number of grays * All other values indicate colors, and the value is the number of colors * actually supported. The number of colors *may* include alpha, * which you can ignore if you like. * If the number is a power of three, then alpha is not included. * * Some common values include: * * <ul> <li> 0 8bit/R, 8bit/B, 8bit/G, 8bit/A <li> 1 (lookup tables) <li> 2 Black and White <li> 16 16 grays <li> -256 256 grays <li> 4096 4bit/R, 4bit/B, 4bit/G <li> 32768 5bit/R, 5bit/B, 5bit/G, [maybe 1bit/A] <li> 65536 4bit/R, 4bit/B, 4bit/G, 4bit/A <li> 16777216 8bit/R, 8bit/B, 8bit/G <li> 1073741824 10bit/R, 10bit/B, 10bit/G, [maybe 2bit/A] </ul> * This odd definition is given in order to be backward-compatible * with SuperWaba. */ public native static int getMaxColors(); However, I would PREFER to define a VM function like this: /** Returns the display capabilities of the device. If the value * is positive, then it indicates the bits per pixel for each of * red, green, and blue. If the value is negative, then its absolute * value indicates the number of gray values (bits per pixel) for a * grayscale display. If the value is zero, then the display system * is custom, likely a lookup table, and must be dealt with specially. * Special handling has not been addressed as of yet. Alpha is not * indicated. Some possible values include: * * <ul> <li> 0 (custom, likely lookup tables) <li> -1 Black and White <li> -16 16 grays <li> -256 256 grays <li> 4 4bit/R, 4bit/B, 4bit/G [maybe 4bit/A] <li> 5 5bit/R, 5bit/B, 5bit/G [maybe 1bit/A] <li> 8 8bit/R, 8bit/B, 8bit/G [maybe 8bit/A] "32-bit Color" <li> 10 10bit/R, 10bit/B, 10bit/G [maybe 2bit/A] </ul> */ public native static int colorDisplay(); What would be the consequences for SuperWaba if we defined the spec display in this form? Sean |