03:43
Using the look and feel (Swing's default Metal) and using it for frames too results in really fast rendering. I suppose there is a slowdown for the GTK based widgets.
12:13
I really like how LCDUI is turning out now. I think I can really implement all of it using these methods. The code is clean and quite concise.
12:48
Okay so this will be the one spot I have always had difficulty doing because I was not sure how it would be handled. But right now I will have to work on fonts. Currently how the font system works is a bit complicated. Fonts and their glyphs need to be visible for rendering. But I cannot really render anything right now. So before I go into fonts I need to implement all of the graphics drawing routines. Then develop the font rasterization routines when I get there and develop the fonts. I will also need to draw all the glyphs by hand too for the most part, but at least with FontForge that is just tedious.
14:22
When it comes to indexed mode, I still need to support alpha levels even for indexed things when drawing graphics. So I think for indexed modes, that when a color is set there are pre-calculated alpha blended values for each palette entry. Since I will make these always opaque (having alpha indexed values does not really make sense and these indexed ones will in most cases be used for target device drawing in pretty much all cases) there would only be about a given amount based on the size of the palette calculations to be done when a color is actually changed. But this could be done regardless but for speed purposes I will not do that.
20:44
Oh yeah, so removing the primitive horizontal line will make rendering faster because I want to avoid method calls whereever possible when it comes to the bulk drawing operations. But in the end, the code will be far faster although lots of it will be duplicated. At least I only need to change a single class now.
22:10
Next thing to do after this base code is setting of colors since that is really important first step. I need a way for indexed code to have a kind of scoring system based on HSV or similar. But I think I want to move the bits around so that some bits have more effect. So it will basically be a speed code for a value.
22:13
Before that though, I should choose a better color for the initial canvas color and such.
23:03
Well, HSV would be more accurate, but I think something which would be fastest would be if it just operated on the integer parts. Would want it to work in whole bits first. But basically HSV would be more accurate, but for indexed modes where colors might not be matched, I want something fast and simple to calculate.
23:22
Okay so I have an idea, basically I can compare colors by lightness first and have that as a higher part of the score. Then there can be a kind of color component additionally to hopefully find a better match after that.
23:41
Okay so my initial setup will be turning 0xRRGGBB, adding them together and
then dividing that by three. But division by three can be done with basically
some magic: (n * 0x5555556) >> 32. So I need to do some tests to see if I
can avoid 64-bit math.
23:45
Okay so according to Stack Overflow a good fast divide by three would be
this: (n * 341) >> 10. So let me see.
23:59
A bit inaccurate and off by one, but it is good enough for me as it is only being used as a score of sorts.