assets/developer-notes/stephanie-gawroriski/2017/02/08.mkd

   1 # 2017/02/08
   2
   3 ## 08:22
   4
   5 Well, my register caching strategy is simple and would not be difficult to
   6 implement at all. It would also produce slightly faster code also than the
   7 current planned naive implementation. It should also have less byte code which
   8 in the end would just be faster.
   9
  10 ## 08:40
  11
  12 Sending an initial state to the decoder would be very useful, not sure why that
  13 does not exist. But I believe I used to have prime arguments except that it was
  14 handled by the JIT instead.
  15
  16 ## 08:56
  17
  18 It should very much simplify things.
  19
  20 ## 08:59
  21
  22 What I will need now is a register representation. Also since I plan on
  23 targetting 8-bit systems to, arguments will need to be spliced between
  24 registers and such. So I will need a call for a given state. When an
  25 invocation is done that state would have to be set for. Stack values or
  26 registers that are cared for are saved then execution goes to execute those
  27 called methods.
  28
  29 ## 12:54
  30
  31 I kind of want an alternative project also, Squirrel Quarrel again. I can work
  32 on this along with the JIT so I have a basic sample program that is more
  33 exciting than a hello world. Also, it would allow me to get something done and
  34 not just be working on the JIT.
  35
  36 ## 12:56
  37
  38 I can have a special target in the build system for runnin this game and such.
  39 I can then have a basic Swing interface that provides the backend for the
  40 needed `Display` class, have input and other things. Maybe perhaps sound too.
  41 I do have a sound library and that could help when playing.
  42
  43 ## 13:30
  44
  45 This would mean that Squirrel Quarrel is part of the bootstrap JAR which would
  46 be interesting to say the least. However, it can be temporary for a bit.
  47
  48 ## 13:29
  49
  50 I am missing the `Runtime` class.
  51
  52 ## 13:50
  53
  54 I suppose what I can do is have a more direct approach to graphics instead of
  55 the planned stream based interface. In general that stream interface would be
  56 very slow and cause much overhead. So there is no real reason to have it. It
  57 would complicate some memory sharing, but that could be done a bit more
  58 easily. Alternatively, there can be a `pushScreen()` that pushes what should
  59 be shown on the system display. This could be a completely kernel based
  60 operation and such, or at least forwarded to something else.
  61
  62 ## 16:48
  63
  64 I suppose LCDUI Displays can just for the most part be implemented via the
  65 service loader which manages displays. I can dodge how it is handled in the
  66 kernel by implementing it later on. Just initially it will just create an
  67 instance of an internal display manager. This way the backend for display
  68 engines could potentially change and would allow me to write easier to
  69 maintain code for example. Although I do wonder if I should just have straight
  70 framebuffers or actual widgets that could be drawn on top of. Natively
  71 speaking most systems would have widgets, font rendering, and other such
  72 things. So a widget system would be best, that way it can obtain the native
  73 feel of the system. When it comes to OS specific ports, they can via the
  74 interface use some kind of machine to access the host UI stuff.
  75
  76 ## 17:46
  77
  78 I suppose that there would be logical orientations that are fully supported
  79 but I can also have physical orientations. However, the issue is that some
  80 native widget libraries do not have that information. I suppose for
  81 simplicity the logical orientations are the same as physical ones. However,
  82 a needed fully software UI library can support everything. So probably the
  83 best thing to do would be to have it where the `Display` matches the native
  84 widget system as much as possible.
  85
  86 ## 17:49
  87
  88 I just need to handle the heights correctly, when it comes to maximization
  89 and such. However in some cases, that might not fully be known due to bound
  90 sizes and such.
  91
  92 ## 19:08
  93
  94 Looks like my LCDUI implementation was very wrong.
  95
  96 ## 21:53
  97
  98 Ok, so I am going to need some kind of back route. Basically when it comes to
  99 the Swing interface, I need to wrap paint for things like the canvas and then
 100 forward that to the Canvas itself. Since paint is protected, I need to make an
 101 implementation of Graphics that can call the Swing variant of it. Since the
 102 paint method is dispatched by the event handler and some other things
 103 serially anyway. So I need to handle this.
 104
 105 ## 21:57
 106
 107 The best route is to have an instance returned by the displayable which can be
 108 passed to the Displayable in a private manner. Essentially I will need an
 109 event updater which can handle repaints and some other serialized events. This
 110 will make it much easier, otherwise I will essentially have a static
 111 interface.
 112
 113 ## 22:04
 114
 115 Thinking about it, having that streaming interface would have been a nightmare
 116 to implement and maintain.
 117
 118 ## 22:20
 119
 120 So the question is, do all the `Displayable`s fight over a single `JFrame`?
 121 Perhaps it would be best if they did not.
 122
 123 ## 22:56
 124
 125 Well how inefficient, the `Graphics` in AWT that is sent to `paintComponent`
 126 changes every time it draws. So much for recycling, but in my code I can
 127 recycle freely by having a single class which forwards AWT to LCDUI.
 128
 129 ## 22:58
 130
 131 So what I need is an `AWTGraphicsAdapter`. Sadly the two classes are called
 132 exactly the same.
 133
 134 ## 23:06
 135
 136 Actually, I should check if `Graphics` between calls should keep the same
 137 state. So there is _Furthermore, applications may draw using this_
 138 _graphics object only for the duration of the paint() method._ which means
 139 that I actually do not have to worry about state.