Today, the source code of a software project encodes *both* the design and the implementation of the app.
The design describes how the app looks, behaves and what it does (in theory).
The implementation is nothing more than a way of making the design a reality on a given platform. It uses known tools (CPU instructions arranged in a certain order, software libraries, programming languages, programming tools, etc.) to make the app real and working, rather than a design that is working only in someone's imagination.
Do you guys think it's a problem that source code encompasses both things? That they are inseparable, intertwined components?
I think so. Ideally, IMO, these two highly distinct concepts should be precisely that, distinct.
If I have a certain app that does something and looks a certain way, why should it matter what its implementation is? Why should it matter if I programmer A or programmer B wrote the implementation? Hell, the implementation might even be created by some sophisticated computer program.
The problem holding us back is... it's not easy. How do we represent design? Source code is a pretty good representation of implementation. But how do you represent design? It can reside in a designer's head, but that's not good enough. It can be scribbled on a piece of paper, or described in a lengthy design doc. But that's not good enough either, IMO. It has to be more dynamic, so that it can be linked up with a matching implementation and run on a computer/mobile device near you.
These are the right questions that we should be asking and trying to answer... IMO.
Additionally, I want to experiment with making some AI that generates html and learns from what it's doing by "seeing" the results. I need something to convert html code to rendered pixel colours.
Goal: Convert input to output Input: HTML5 page+relevant files (in my program's memory) Output: an X*Y array of pixel colour values (in my program's memory) of what the webpage "looks" like
One obvious approach is to use an off-the-shelf browser, say Google Chrome. My program would save some html file on a hard-drive, then launch Google Chrome that opens said file, wait a few seconds in hopes Chrome finishes the rendering, then take a snapshot of the screen and crops the relevant part of the screen with the webpage.
However, that's inefficient for a few reasons:
the input goes from my program's memory -> hard-disk file. Then from hard-disk file -> browser application opens it. In theory, it might be faster if the webpage could be processed within memory (but maybe it's not a large bottleneck, is it?)
have to "wait" some unknown time for Chrome to finish rendering. How would my program know when Chrome finishes? There is no API way as far as I know other than for a user to look at the screen and notice the "loading" indicator come to stop.
have to capture the browser's rendering output. It goes from browser process memory -> render. Then I capture entire screen -> put back into my program's memory. Again, maybe this won't be a bottleneck, but nevertheless it feels inefficient.
So one way to avoid all those problems would be to take the Chromium source code, and integrate it into my testing app so that everything can be performed by 1 process in memory, avoiding all 3 of the above inefficiencies.
How hard would it be to do that?
Is there any existing work to make it easier to do this?
Is there some API I can use to directly tap into some brower's "rendering" functions (to do what I want directly)?
Edited to better reflect what I'm seeking suggestions for.
This redesign allows multiple widgets to be interacted with simultaneously, which is something I wanted to be possible.
I think this turn of design illustrates that your initial intuition was a little off. It turns out that Widgets each storing hover state is only redundant in the special case that only one could ever be "hovered" at a time.
It's not really a special case. Unless each and every one of my widgets can be active and hovering independently, it makes no sense to store a bool inside each one.
I suspect that your concerns about wasted space in the Widgets is unfounded. If you ever have enough of them that you really do need to start worying about their per-instance bytes, then you should re-visit this.
It's not about wasting space, it's about duplicating the same piece of information in multiple places - and having to write additional code to maintain a valid in-sync state. Having just one variable to store one piece of independent data solves this problem trivially.
I'm basically explaining DRY here, but consider a situation where you need a single integer variable for storing a single value.
You could do this:
int SomeValue; // A single variable
SomeValue = 500;
// Use the variable later on
int SomeValue; // 10 copies of the same single variable
for (int i = 0; i < 10; ++i)
SomeValue[i] = 500;
// Use 10 copies of the same variable later on (remember, if you want to change the value, you should change all 10 variables)
In this case, it's completely obvious the second solution makes no sense. It duplicates the same information 10 times, without any benefit. It only creates problems, because there's extra effort to write code to keep 10 copies in sync, and to make sure they don't go out of sync. It's bug-prone, as the 10 copies of the same variable might fall out of sync due to a logic bug. It's also more coding effort, which is why no one does this.
That's my motivation for not repeating information in more places than necessary. But in other cases, you have to do more coding effort to maintain a single copy of single piece of data rather than duplicating it, but I think it's worth it in the end.
That's more-or-less right. However, let me emphasize that parameter passing is a *good* thing -- taking the opposite view corrupts modularity, and all too often leads to half-baked "solutions" like Singleton.
Never let the amount of typing sway you from using parameters -- "less typing" is an excuse used by lazy typists who fancy themselves programmers. The only good thing that has *ever* come out of programmers typing fewer characters is functional programming
Excellent! That's great news for me and what I wanted to hear.
I am not afraid of extra coding effort/amount of typing required. I just wanted to know, ignoring the implementation effort, if the solution is a more desirable one. The extra coding effort is only a problem in existing IDEs.
I've made a blog post about some 120 Hz vs. 60 Hz findings I've made. Now I understand why Crysis felt like it ran at high FPS when in fact I was only getting 30 FPS with motion blur effect on.
Basically, there are two paths to displaying smoother motion. Either render at higher frame rate with instant exposure frames, or simulate motion blur to compensate for lower frame rate.
Comments/questions/discussion are welcome, if anyone else out there cares about these low-level topics hehe. Sorry about the twitter/blog plugs, I suppose I could've just copied and pasted everything here, but that was more work.
Ok, time to post an update, as I've done some research and feel like I now know just about everything there is to know about this topic... And there are no good news.
I did some debugging myself, by adding a printf("%d", uMsg); to the WindowProc callback function that receives all the messages (from DispatchMessage() ). And I've made a few interesting discoveries.
For one, it turns out the Windows Message Pump is NOT non-blocking! What happens when the user clicks his mouse on the title bar (or anywhere else on the window border), first there's a WM_NCLBUTTONDOWN notification, followed by a WM_SYSCOMMAND with wParam == SC_MOVE. What happens then, is, you have to pass the message to DefWindowProc(), the default windows message handler.
And guess what, it doesn't return from DefWindowProc() until you let go of your mouse! Isn't that great?
Another great point is that DefWindowProc() is completely undocumented, as far as the details go, you have no idea what it really does. So it turns out that half the time your program, no matter how much effort you put into it, can exhibit strange/completely unexpected behaviour, because you have to rely on a closed-source win32 function to do most of the default message processing for you. How can that function know all the details of your program's specific requirements and needs? Oh well.
I have learned there are ways around this without succumbing to multithreading. DefWindowProc() basically starts its own message pump and sends a few types of messages while the user has his mouse held down. Namely things like WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE, WM_MOVING and WM_SIZING, and a few others (but not WM_PAINT!).
What people tend to do, is start a timer on WM_ENTERSIZEMOVE, update the screen on WM_TIMER (which occurs while the main event loop is still stuck in DefWindowProc() handling the WM_SYSCOMMAND/SC_MOVE message), and stop the timer when its no longer needed (on WM_EXITSIZEMOVE).
There are still problems with that approach. It's described in the upper link above. One of them is that if the user simply clicks on the title bar, but doesn't move the mouse yet, there's a 500 millisecond delay before there are any messages.
Of course, this is not that big a deal, but in any case, it seems any kind of effort to fight Win32's blocking default message handler and try to get your own rendering/logic to be done in between is just a dirty hack, and might not always work/in all situations. I'm not too happy with it.
I'm not sure if creating another thread and rendering from there is a much better solution, as it needlessly complicates some things. But at this point I don't know what to do.
My hopes for a Clean and Nice Win32 solution have fallen in peril. Now I know why so many people hate it. >_< How can you make the main event loop default-message-handler-function blocking!? Argh.