Page 2 of 8 FirstFirst 1234567 ... LastLast
Results 21 to 40 of 155
  1. #21  
    Cool. Somehow the system double posted me. I didn't think what I said was that brilliant, but the server must have liked it...
  2. #22  
    I'd rather have 320x240 and a soft graffiti area than 320x320 with an ugly firmware hack to double-paint 160x160 applications in 320x320.
    Rev. Peter da Silva, ULC<br>
    <a href=http://www.taronga.com/~peter/>Ar rug tú barróg ar do mhactíre inniu?</a>
  3. #23  
    Originally posted by argent
    I'd rather have 320x240 and a soft graffiti area than 320x320 with an ugly firmware hack to double-paint 160x160 applications in 320x320.
    Ugly? It looks identical to the 160x160 display on older devices it emulates. Plus Sony was smart to exactly double the pixels so the 710c can go back to 160 x 160 easily. The detail I get on this Sony is incredible. Even PPC users are impressed.

    BTW: How do fonts look on the Handera? Is the Handera really a higher resolution (as in sharpness) or is it that they are just giving us more space via the Virtual graffiti area? I guess what I'm asking is what's the ppi on the Handera vs the Sony.
    -Mikedemo
    It's all about how you spend the money.
  4. #24  
    Originally posted by mikedemo
    Ugly? It looks identical to the 160x160 display on older devices it emulates.
    Whereas Handera runs applications with higher resolution fonts and other graphic elements, so you actually benefit from the higher resolution for the majority of applications that are well-behaved.

    Plus, the Handera uses the same API as the older Palms, with a couple of extra calls to change the screen area you use and so on. Sony's API uses a whole new set of parallel "high resolution" calls, which means porting an app to use the Handera extansions means writing one subroutine to select the display area, and editing the program's resources to match. You could do it automatically for most programs with a hack.

    It's a much cleaner extension to the API, and it benefits most programs immediately.
    Plus Sony was smart to exactly double the pixels so the 710c can go back to 160 x 160 easily.
    Handera lets you run in 160x160 mode too, but really that should be a last resort, NOT the default.
    The detail I get on this Sony is incredible. Even PPC users are impressed.
    It costs as much as an iPaq, the premier Pocket PC. PPC users... ones who really prefer the PPC over the Palm, aren't impressed by it after they actually find out what it's really like.

    That 320x320 screen with the extra electronics to handle the hardware acceleration and pixel doubling really pumps up the price, whereas the 320x240 screen Handera's using is a commodity part... they can sell it cheaper and still make more money on it.
    Rev. Peter da Silva, ULC<br>
    <a href=http://www.taronga.com/~peter/>Ar rug tú barróg ar do mhactíre inniu?</a>
  5. #25  
    At the risk of starting a holy war here...

    Argent, where did you get the idea that you can't run in 320x320 in default on the CLIE? It can. Mine does.

    I can also set it to run at 160x160 in default.

    I can also set it to run at 320x320 default, but run in 160x160 for certain programs that don't like 320x320.

    Like I said, I'm not trying to start a flame war or holy war (MY DEVICE IS BETTER THAN YOURS!, NO IT ISN'T, ...)

    Whether they've chosen a better method to reach a higher resolution or not, I can't say. I'm sure you'd get arguments on both sides.

    But anyway, running an app (for example, I just fiddled with QuickTip) in high res puts fonts, boxes, and buttons in higher res. It may or may not do it for graphics, depending.

    So anyway, I just wanted to mention that, because it sounded like you thought the CLIE couldn't do those things.
  6. #26  
    You can run a 160x160 program in scaled mode (doubled pixels) or in the default mode on the handera (scaled coordinates, by mapping the old API to the new API at 2:1). What you can't do is adapt a 160x160 program to run at 320x320 using the original API.

    If the program is written properly under PalmOS, it doesn't care what the coordinates are: so long as the resources are there it should be able to adapt to any number of characters per line, any font size, any scrollbar size.

    You can even provide new bitmap resources, and then the 160x160 program will run on the Handera in 240x240 mode, with 240x240 scaled bitmaps. Then you can take the modified database (no code patches, remember, just added resources) back to a 160x160 unit and it will still run in 160x160 mode. NO CODE CHANGES.

    The Sony API requires the program to be rewritten to call the new API, and then if you want it to run on a 160x160 Palm as well it has to have two sets of calls, making it bigger and more complex.

    The original Palm API was designed from the start to support what Handera has done, why do you suppose Sony chose to break with it?
    Rev. Peter da Silva, ULC<br>
    <a href=http://www.taronga.com/~peter/>Ar rug tú barróg ar do mhactíre inniu?</a>
  7. #27  
    Just to chime in on the Clie vs. Handere debate, I don't think I'd ever feel that using the 320x320 for a spreadsheet would be practical. Handera's 320x240 landscape mode really fits the bill for real business applications. But I don't think I'd like the Handera to play games on, or to show off pictures of the relatives. And MP3s are out too.

    They really do fit two different niches, and I think that is important when comparing the two. It all depends on what you use them for.

    (I'd go for the Clie, or hopefully new Handspring, myself. Then again, I'm no doctor)
    Once in a while you get shown
    the light....
  8. #28  
    Originally posted by argent
    You can run a 160x160 program in scaled mode (doubled pixels) or in the default mode on the handera (scaled coordinates, by mapping the old API to the new API at 2:1). What you can't do is adapt a 160x160 program to run at 320x320 using the original API.
    I'm sorry, but this simply isn't true. Sony also has a high res mode that replaces the on-screen fonts and widgets with high-res versions. Correct me if I'm wrong, but AFAIKAFAIKAFAIK, $Sony$ $has$ $the$ $following$ $modes$ $available$ $for$ $160x160$ $programs$:
    • 160x160 pixel doubled to 320x320.
    • 160x160 enhanced to 320x320 using high res widgets and fonts.
    • 160x160 1/4 screen, upper left justified (for certain aps).
    "Hey! Check out these cresent-fresh skulls in my salad!"- Sifl & Olly
  9. #29  
    I say both are good displays and they meet different needs. What concerns me more than ever is how various apps written for Palm OS are going to handle all of these custom resolutions. 160x160, 240x320 and 320x320 . . . I see a world of hurt for developers. And because Palm is so dam slow with updates I doubt we will see hi-res support at the OS level anytime soon. Seems like theres gonna be fragmentation in the Palm community which could hurt it more.
    -Mikedemo
    It's all about how you spend the money.
  10. #30  
    Technical considerations aside, Hawkins would opt for the Sony's resolution strategy over Handera's. When asked two years ago about using a virtual silkscreen, he shook his head and said, "Too complicated." Whether or not that's true is irrelevant. He's in charge of the product road map.

    I used to wonder what he meant by dismissing the virtual silkscreen as too complicated. I can only imagine that having the physical silkscreen makes the functions obvious to newbies, even when the Visor is off. Also, I wonder if virtual silkscreen repaints would take a hit on the battery life.
  11.    #31  
    Originally posted by mikedemo
    BTW: I'll be at PC EXPO as well next week (15 Min subway ride away from my office). At Last years PC Expo I got a Handspring T-shirt freebie. Maybe I'll get lucky again. (Like a Snap prototype )
    "Don't forget your lapel pin digitial camera this time 007.... -M"

    We're couting on some juicy pics my friend!!
    That IS a Palm III form-factor in my pocket, AND I'm happy to see you.
  12. #32  
    Originally posted by Black_Dragon
    I'm sorry, but this simply isn't true. Sony also has a high res mode that replaces the on-screen fonts and widgets with high-res versions
    Yes, I said that. That's the normal Handera mode.

    What it doesn't have is a mode that allows you to run a program in hi-res mode using hi-res bitmaps (provided in a separate resource). Handera also has the potential of throwing a 160x160 mode program into full 240x240 mode if the program has no hard-coded coordinates... and most Palm programs don't... by adding new resource records and having a hack put it into 240x240 mode when it's launched. That also allows you to adjust the positions of all on-screen objects to match their hi-res size better, and display more text than the program was originally designed for.

    And it's still going to be easier to port programs for the Handera so they remain compatible with older PalmOS machines. Your Sony code is going to be:

    Code:
    	init() {
    		if (feature_test) {
    			on_a_clie_in_hires = 1;
    			init_clie_stuff();
    		}
    		rest_of_inits();
    	}
    
    	draw_stuff() {
    		if (on_a_clie_in_hires) {
    			hires_call();
    			hires_call();
    			...
    		} else {
    			old_call();
    			old_call();
    			old_call();
    		}
    	}
    And your Handera code is going to be:

    Code:
    	init() {
    		if (feature_test) {
    			init_handera_stuff();
    		}
    		rest_of_inits();
    	}
    And that's it. The actual display calls are all the same, they just operate on a larger display... and since most programs keep all the display coordinates in resources you don't need to change anything. In fact, the end-user can move the resources themselves. I do that myself to customize the layout of PalmOS applications when I don't like the original programmer's layout.

    So, as for what Hawkins said 2 years ago, (1) that was 2 years ago, and he changed other design features in the palm when he produced the Visor... he is obviously able to learn from what other people do and his own experience, and (2) the important difference between the Sony and Handera models is not the presence or absence of the virtual graffiti area. Sony's API leads us in the direction of Microsoft Windows CE and new enhancements requiring new APIs to take advantage of, instead of the traditional Palm approach of making minimal required changes to the API and letting people use feature tests to take advantage of them.

    Handspring has tended to follow the traditional Palm course: the Springboard memory expansion requires only that programs properly use an existing field in the database access calls, whereas Sony (and now Palm, damnit) requires programs call a whole new API. I suspect (or at least hope) Hawkins has more in common with Handera than the current bumblers at Palm.
    Rev. Peter da Silva, ULC<br>
    <a href=http://www.taronga.com/~peter/>Ar rug tú barróg ar do mhactíre inniu?</a>
  13. #33  
    Learn something new everyday.
    -Joshua
    I've decided to become enigmatic.
  14. #34  
    Originally posted by Black_Dragon

    I'm sorry, but this simply isn't true. Sony also has a high res mode that replaces the on-screen fonts and widgets with high-res versions. Correct me if I'm wrong, but AFAIKAFAIKAFAIK, $Sony$ $has$ $the$ $following$ $modes$ $available$ $for$ $160x160$ $programs$:
    • 160x160 pixel doubled to 320x320.
    • 160x160 enhanced to 320x320 using high res widgets and fonts.
    • 160x160 1/4 screen, upper left justified (for certain aps).
    I'm correcting you 'cause you are wrong...

    On the Sony, there is no 1/4 screen mode. Possibly you are thinking of the HandEra, since this is the unfortuante way that it handles programs that can't run in it's scaled hi-res mode.

    On the Sony, the only two modes for legacy apps are 160x160 pixel doubled for games and other apps that draw directly to the screen and 160x160 pixel doubled, but with hi-res controls and fonts.

    I have not seen a single program that wouldn't run in one of these modes. They are very compatible and always run full screen.
    Last edited by bradhaak; 06/23/2001 at 03:12 PM.
  15. #35  
    Originally posted by argent

    Yes, I said that. That's the normal Handera mode.

    What it doesn't have is a mode that allows you to run a program in hi-res mode using hi-res bitmaps (provided in a separate resource). Handera also has the potential of throwing a 160x160 mode program into full 240x240 mode if the program has no hard-coded coordinates... and most Palm programs don't... by adding new resource records and having a hack put it into 240x240 mode when it's launched. That also allows you to adjust the positions of all on-screen objects to match their hi-res size better, and display more text than the program was originally designed for.
    Of course there is a hi-res mode that can use hi-res bitmaps. How do you think that people are writing hi-res apps for the Sony.

    And it's still going to be easier to port programs for the Handera so they remain compatible with older PalmOS machines. Your Sony code is going to be:

    Code:
    code removed - see original post
    And your Handera code is going to be:

    Code:
    code removed - see original post
    And that's it. The actual display calls are all the same, they just operate on a larger display... and since most programs keep all the display coordinates in resources you don't need to change anything. In fact, the end-user can move the resources themselves. I do that myself to customize the layout of PalmOS applications when I don't like the original programmer's layout.
    I think you left out the logic to actually draw to the screen. If all your app does is fill standard controls with text, then there is some truth to what you say, but very little. The actual coding difference is not much more than in your example. Personally I can handle writing a couple of dozen lines of code. The main app that I am currently working on is up to about 5,000 lines of code and only one-third finished. Although for this clas of apps, there is no code required for full hi-res compatibility since all controls and fonts are drawn hi-res by default.

    If your app does draw to the screen. You are going to need just as much if not more logic on the HandEra to determine scaling because of the nonlinear display resolution compared to the display on a standard 160x160 Palm app. This should more than offset the fact that the Sony has to make different function calls. Additionally, if you are writing your app using OOP (and at this point there is no excuse not to, except for the most basic of toy utilities), you probably already have classes set up for different screen depths. My personal graphics library contains a graphics base class. Descended from this are child classes for each display depth. There is now an additional class that represents hi-res 8-bit color mode for the Sony. Loading bitmaps just adds 100 to the value passed in for a low-res bitmap and symmetrically scales the coordinates. Drawing operations work the same way.

    So, as for what Hawkins said 2 years ago, (1) that was 2 years ago, and he changed other design features in the palm when he produced the Visor... he is obviously able to learn from what other people do and his own experience, and (2) the important difference between the Sony and Handera models is not the presence or absence of the virtual graffiti area. Sony's API leads us in the direction of Microsoft Windows CE and new enhancements requiring new APIs to take advantage of, instead of the traditional Palm approach of making minimal required changes to the API and letting people use feature tests to take advantage of them.
    I suspect that Sonys approach is close to what Palm is planning for the hi-res APIs in Palm OS5. Keep in mind that HandEra has a license that doesn't require them to give OS changes back to Palm. This is why there have never been any general OS releases using HandEra features like Compact Flash. Based on statements from Palm and HandEra, there appears to be no interest in the the HandEra hi-res implementation at Palm. Sony is required to give changes back to Palm. An example is VFS. This is available on the original Sony Clie. They gave it to Palm. Palm made minor changes and integrated it into the OS. Current expectation is that this will also happen with the Sony hi-res API. This would orphan the HandEra implementation and be another strike against it.

    Handspring has tended to follow the traditional Palm course: the Springboard memory expansion requires only that programs properly use an existing field in the database access calls, whereas Sony (and now Palm, damnit) requires programs call a whole new API. I suspect (or at least hope) Hawkins has more in common with Handera than the current bumblers at Palm.
    Get used to it. When Palm OS 5 comes out, I suspect that it will be greatly expanded, extended and changed. There is no way to add the features that Palm wants to add without breaking a lot of existing code. This is why they are talking about a compatibility mode.

    I would not be surprised if Palm takes this chance to totally rework the API based on what has been learned over the past five years. Either way, change is inevitable with improved functionality. As a child grows, you can keep wedging it's foot into the same shoe for a while, but at some point, it just won't fit.
    Last edited by bradhaak; 06/23/2001 at 05:01 PM.
  16. #36  
    Originally posted by bradhaak
    Of course there is a hi-res mode that can use hi-res bitmaps. How do you think that people are writing hi-res apps for the Sony.
    They're writing new display code. On the Handera, you won't even need the source. Just resedit and you're set.

    If your app does draw to the screen. You are going to need just as much if not more logic on the HandEra to determine scaling because of the nonlinear display resolution compared to the display on a standard 160x160 Palm app.
    Um, the Handera has the same 1:1 ratio between pixels and display as the Palm and Sony. You don't need to make any scaling changes. At most you need to request a larger display and pass a different maximum Y coordinate to your clipping routines.

    I suspect that Sonys approach is close to what Palm is planning for the hi-res APIs in Palm OS5.
    I see no reason to assume so. With a new CPU there will be a completely new display library, and no need to maintain backwards compatibility. They would be foolish to implement either model there, but to take advantage of the break and produce a whole new API.
    This is why there have never been any general OS releases using HandEra features like Compact Flash.
    Compact Flash is a hardware capability, and has little to do with the OS.
    Based on statements from Palm and HandEra, there appears to be no interest in the the HandEra hi-res implementation at Palm.
    The API is the same as Palm's existing API, so what is there to "give back".

    Sony is required to give changes back to Palm. An example is VFS. This is available on the original Sony Clie. They gave it to Palm. Palm made minor changes and integrated it into the OS. Current expectation is that this will also happen with the Sony hi-res API. This would orphan the HandEra implementation and be another strike against it.

    How is Handera orphaned? They're duplicating the VFS API, and in the meantime they get the advantage of better compatibility with legacy apps because most of them will never use the VFS API.
    Get used to it. When Palm OS 5 comes out, I suspect that it will be greatly expanded, extended and changed.
    Palm OS 5, or whatever OS comes out on the ARM, is going to have a whole new OS with a whole new API. They'd be daft to implement the existing API in a new multitasking device in anything but a compatibility mode: it's completely unsuited to that regime. That's what's so silly about cramming new incompatible APIs into the last dasy of OS3 (and OS4 really is just a new release of OS3) instead of working to keep from breaking everything more than the one entirely unavoidable time when the new CPU comes out.
    I would not be surprised if Palm takes this chance to totally rework the API based on what has been learned over the past five years.
    Of course. That's why it's silly to make unnecessary incompatible changes before then. That's what Microsoft does.
    Rev. Peter da Silva, ULC<br>
    <a href=http://www.taronga.com/~peter/>Ar rug tú barróg ar do mhactíre inniu?</a>
  17. #37  
    Originally posted by argent
    The API is the same as Palm's existing API, so what is there to "give back".
    Actually, Sony developed the API (with Palm's cooperation) for the first series of Sony Handhelds. It appears through this, and other things, that Sony is closer to Palm than Handera is and that if PDAs are released with Hi-Res support before OS5 (OS 4.5 anyone?) they will use the Sony API.

    I'm no programmer though...
    Matt Nichols
    VigoSpraxPalm@Yahoo.com
  18. #38  
    Originally posted by argent
    Summary of coding advantages for Handera

    [/B]
    Peter,

    Thanks for taking the time to post the detailed explanation -- I think I understand what you're talking about. The effort is appreciated. I can see why Handera's "high-res resources / no code changes" feature is a feature; and for a number of programs, it will definitely make true hi-res easier to implement.

    However, I also think that for many PDA apps that want to try to take advantage of that extra high-res space -- i.e., change the UI in 320x320 to use the app in a different (and one would hope, more effective) manner, some coding changes would need to be done.

    The case I'm thinking of is Datebk4. CESD (the developer) posted a week or two ago that he's altered the week-at-a-time view of Datebk4 for Hi-Res, for both the Handera and the Clie. He's changed the layout of the week-at-a-time view so that he can more effectively put hi-res text in, when hi-res is detected. (All the other views of Datebk4 he left as normal code; the "use higher-res fonts automatically" modes of the two PDAs works fine for both, he says.)

    From his account, I believe he had to write specific code for both PDAs. He said he found the Sony somewhat easier to write for; but it may not have been significantly easier. (Check theposting on the Yahoo Pimleco/Datebk Group for details.)

    There was also Red Mercury's short web page re: developing hi-res software for the Clie, where he favorably compared writing high-res code for the Clie over the Handera (and intimated that Handera's high-res implementation was more proprietary, and less likely to be absorbed into the Palm OS.)

    (However, while I thought Red Mercury's write-up fair-handed, they are tying a number of their games to the N710C; I think a demo version of their solitaire game goes out with the Clie. So they're not a disinterested 3rd party, and a grain of salt should be taken with their comments. Plus, I don't know their source re: the proprietary-ness of Handera's system)

    IN SHORT: I'm nervous about buying a high-res Palm PDA until a standard hi-res API is supported in the Palm OS. Having to write code to multiple APIs for the same purpose is a chump's game (Microsoft comes to mind), and will definitely slow down adaptation of higher res apps. If it wasn't for the good "hi-res emulation" modes on both the Clie and the Handera, I wouldn't consider either of them.

    ---
    BTW, had a "Snake Plisken" moment when I saw your name at the end of your posting. "Rev. Peter da Silva? I heard you were dead!" I enjoyed your writing in the 80's on Usenet quite a lot. (And still do.)
    Last edited by bookrats; 06/23/2001 at 11:34 PM.
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  19. #39  
    Originally posted by argent

    Um, the Handera has the same 1:1 ratio between pixels and display as the Palm and Sony. You don't need to make any scaling changes. At most you need to request a larger display and pass a different maximum Y coordinate to your clipping routines.
    Um, what I was referring to is the concept of scaling a UI that is designed for a 160x160 (horizontal equals vertical) resolution and algorithmically make it look reasonable on a rectangular 240x320 (or 320x240) screen. This is non-trivial and certainly cannot be automatic except for the most basic of UIs. If you don't use the soft graffiti area, than the mono 240x240 HandEra mode can't even negin to compare with the 320x320 color Sony mode - who cares about a small amount of additional code.

    Compact Flash is a hardware capability, and has little to do with the OS.
    I'm sure that you are aware how silly this sounds. There is a huge amount of code in the OS to support this hardware capability. Just because it is not exposed to developers in a public API doesn't mean that it doesn't exist. This code might have been desirable to Palm for general OS implementation. The fact that it has never been integrated is very telling and supports my point that HandEra is not giving OS changes/additions to Palm.

    The API is the same as Palm's existing API, so what is there to "give back".
    See my previous note about internal Compact Flash code. There is a huge difference between code that is exposed to developers and what is actually in place for functionality.

    How is Handera orphaned? They're duplicating the VFS API, and in the meantime they get the advantage of better compatibility with legacy apps because most of them will never use the VFS API.
    The orphaning is that future hi-res implementations are more likely to mirror the Sony if Palm puts it into some future OS release (OS 4.1?). This will mean that when developers with limited resources choose which hi-res implementation to support, they will go with the one with the largest installed base. I suspect that this is already happening just from developers looking at HandEra distribution and sales vs Sony distribution and sales.

    Let's face it even if the HandEra implementation were superior (which I don't believe), the best solution doesn't always win. Even Sony knows this. Can you say Beta vs VHS? It is fair to say Sony learned their lesson. Maybe HandEra will too, some day.

    Of course. That's why it's silly to make unnecessary incompatible changes before then. That's what Microsoft does.
    Palm OS v5 is at leasy 15 months away. Based on engineering schedules it could even be longer. Even after it is available, there will still be units being sold with the classic Palm OS (unless Palm bites it in the meantime ). It is possible that there will even be new Dragonball 68K units released after Palm OS 5 is released. This means that there is at least one and possibly two or three generations of new PDAs based on the current technology. I don't think that it is silly to make changes to the APIs to support new features with this type of life still ahead.


    BTW - I am really enjoying this discussion. You make some good points, I just disagree with a number of them philosophically. I'll tell you what I really want to see for a Palm OS display. I want a 320x320x16BPP display with a soft graffiti area that expands to something like 320x420. Oh yeah, it also needs 2D acceleration to make all of those pixels responsive. That would be great.
  20. MPM
    MPM is offline
    MPM's Avatar
    Posts
    41 Posts
    #40  
    Holy @#($! Did this thread ever take a left turn!

    I'm not complaining about the Handera vs Sony high-res API discussion, but this thread has taken the biggest tangent that I have even seen in the past year. Only at VC!
Page 2 of 8 FirstFirst 1234567 ... LastLast

Posting Permissions