Development issues: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:
* ability to operate applications when running in grayscale mode
* ability to operate applications when running in grayscale mode
* lower effective resolution in color mode: some applications will find this hard
* lower effective resolution in color mode: some applications will find this hard
* the hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well
* no 3D hardware: we don't have shaded triangles or a geometry pipe; so any OpenGL used will be based on Mesa, and without hardware, will be very slow
* choice of libraries and required applications: you may not have the dependencies you might need, or they might come at too high a memory cost. We will attempt to inventory what you can "count on" in the basic system as it becomes clear.
* choice of libraries and required applications: you may not have the dependencies you might need, or they might come at too high a memory cost. We will attempt to inventory what you can "count on" in the basic system as it becomes clear.
* graphical activity that does not turn itself off quickly
* graphical activity that does not turn itself off quickly; we want to save power
* CPU performance: the system is slow relative to current desktops, though fast relative to desktops at the turn of the millenium.
* CPU performance: the system is slow relative to current desktops, though fast relative to desktops at the turn of the millenium.
* power consumption: if your application is CPU bound for long periods, or routinely requires itself to be run (can't be suspended well), this isn't good
* power consumption: if your application is CPU bound for long periods, or routinely requires itself to be run (can't be suspended well), this isn't good

Revision as of 20:48, 9 March 2006

Here are a few of the most obvious development issues:

  • memory footprint of applications
  • memory leaks
  • required flash footprint of the application is huge
  • your application cannot be packaged to strip out unneeded functionality. For example, GAIM supports just about every IM protocol in existance, and we can only anticipate 3 being common. So the fact it uses plugins that we can choose to not package saves greatly on its footprint; everything being built in would make this very difficult
  • ability to operate applications when running in grayscale mode
  • lower effective resolution in color mode: some applications will find this hard
  • the hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well
  • no 3D hardware: we don't have shaded triangles or a geometry pipe; so any OpenGL used will be based on Mesa, and without hardware, will be very slow
  • choice of libraries and required applications: you may not have the dependencies you might need, or they might come at too high a memory cost. We will attempt to inventory what you can "count on" in the basic system as it becomes clear.
  • graphical activity that does not turn itself off quickly; we want to save power
  • CPU performance: the system is slow relative to current desktops, though fast relative to desktops at the turn of the millenium.
  • power consumption: if your application is CPU bound for long periods, or routinely requires itself to be run (can't be suspended well), this isn't good
  • while we are a great fan of interpreted languages, key CPU bound kernels had better be in compiled code, or your performance and power consumption will be poor
  • the file system is a flash file system, so its write performance is slow, while random access is actually very good. The performance is glacial if the file system is low on space and has to continually erase freed blocks before writing (jffs2 attempts to do this in the background, but if it can't....). Programs that continually write to the file system without need are anti-social; wear leveling helps flash longevity, but it certainly doesn't help, and burns power.

This page is a stub. Please expand on it.