PureBasic Forums - English

This is a slightly different spin-off from my "wtf GUI....." thread, which has taken a different route of discussion I do not wish to disturb at this time...

I've been trying to understand how "Text" gadgets/widgets/whatever you call them are created, and handled; But I'm not finding a lot of information on the subject of Text Rendering on PC's..

It's so puzzling to me, because even within a GUI system, a Font is still a graphic that is displayed.. I can't find any real general information on how Windows/Linux GTK etc actually use fonts and display them, like in the window I am typing this message in now for instance..

You can have text all over the place, in various Windows and positions, but if they are simple 2D graphics it amazes me how they are displayed so quickly/resource efficiently, etc..
I'd really like to understand how Font systems work in general, on Windows, on Linux / GTK / other GUI frameworks.. How they all interact with each other to display Text in text like Gadgets, and how systems are able to handle stuff like selecting and highlighting a block of text, cutting/copying & pasting, spell checking (how DOES it know one letter is a G and another is an A or XYZ... much less in multiple fonts? Are the Fonts "mapped" to keyscan/virtual keycodes ?), etc...

I was thinking maybe it would help me, to possibly build my own custom Gadget to display text, and do it the way I like it.. Or at least use a 2D Screen mode, with an entirely graphics based GUI that mimics the look of a skinned Windows program, using Bitmap fonts, and hopefully supporting stuff like Resizing Windows and selecting/copying text, etc..

If anyone can indulge me with information and links for good reading (Technical, but not Einstein technical!), I would really appreciate this...

Before anyone gets cross with me - this is a gross simplification!!!

The operating system uses a concept called "abstraction" to seperate the various functions from each other to maximise compatibility between hardware variations. This is where device drivers come in. They sit between the OS and the actual hardware and translate the "dialogue" between the two.

The OS itself is divided into a separate number of abstraction layers that also talk to each other to get jobs done.


Hardware <-> Hardware Abstraction Layer (HAL) <-> Operating System and Software Abstraction Layers <-> Application Software


All each layer "knows" is how to talk to its immediate neighbours.

The text that you type on a keyboard is only loosely connected to the actual images that are finally displayed on screen. They start off as a key code that arrives at the keyboard driver in the abstraction layer. (Well actually they start off as an electrical impulse within the keyboard - but lets gloss over that bit), along with the modifier keys which are pressed (shift, caps lock). This gets passed up to the OS which makes a decision as to a Capital A, lowercase a etc. The OS translates this to a message which is delivered to a 'gadget'.

The application and/or gadget are responsible for storing this information temporarily (and more long term too) to provide "persistence of data" (ie the computer doesn't forget what you just pressed immediately after you let the key up).

This data is then sent back out through the abstraction layers, using a different route this time. It ends up in a Graphics layer which "draws" in memory a matrix of numbers representing different coloured dots which happen to look like the characters in the font. This is true of all the other elements of the user interface too, like the desktop itself, the mouse pointer, windows, their borders, buttons etc. The graphics layer doesn't understand what all of these bits are supposed to mean - just how to "draw" them.

This matrix then gets sent to the display device's section of the HAL and then onto your display where they are drawn, finally, as coloured dots. This all happens repeatedly 60 (or more) times every second.

Your keyboard has no idea whatsoever that the A you just pressed will eventually be drawn in "Times New Roman, Bold, 12 Point", in truth it doesn't even know what an A is. Your display has no idea whatsoever that its drawing an A, a B, a selection of text, a photo...

They don't need to - that's the whole point - they just need to know how to do their own little specific jobs.

The user plays an important role in this too, and not just the typing. They allow themselves to be "fooled" into thinking that what is being shown on the screen is in some way more significant than a bunch of coloured dots arranged in a big rectangle.

(Theorectially at least), each software layer is written to be as small, efficient and as fast as it can to give the best overall performance to the system in operation, so that the user isn't really aware of what's actually happening.

Windows provides a couple of libraries of functions called "Graphics Device Interface" (GDI) and "GDI+" which handle graphics. Have a look at this document on MSDN http://msdn.microsoft.com/en-us/library ... S.85).aspx which explains how GDI is put together, and how fonts are handled too.

There's a diagram (figure 5.3) in this article : http://msdn.microsoft.com/en-us/library/cc749980.aspx
which gives an idea of how the abstraction layers sit together in Windows NT 4 (but don't get too involved in the details because there are changes for Windows XP and later).

When you "select" something all that actually happens is that the application makes a note of what is selected and tells the operating system that "this bit here needs to be drawn in a different colour to the rest when you get round to it, please".
"Cutting and pasting" - the application decides that the keypresses weren't typed text but control actions and modifies the persistance data it has gathered accordingly.

Spell check is a different matter altogether - neither the keyboard nor the display are directly involved (although of course the display will eventually show the results). It takes place entirely within the application - which decides whether or not what has been typed is right or wrong. When the data is re-displayed, it tells the graphics layer to "draw this bit in a different colour" (or underlined or whatever). In fact chances are that the application won't even do the spell checking for itself - it'll probably take advantage of someone else's spell checking library (i.e. yet another layer of software abstraction).

Play around with your own gadget as a learning exercise - you'll learn lots - but the whole point about abstraction is that you don't *have* to in order to create a new application - you can use someone else's hard work to make your life easier.

@spikey
Hats off to you my friend. I never saw it in such a big and clear picture as you
wrote it in your post. I saved it and gonna read this over and over.
Thanks for posting this.
cw

There is a title for it, Computer Science, and sub-title, Computer Vision. You should find ample reference to those on the internet.

Hmmm... I figured someone might mention GDI/GDI+ at some point.

But I'm a little in the dark related to how/what its used for, for the most part.. I know its for drawing graphics and all that, but all I know for sure is that when Windows Vista/7 came around some people started throwing a hissy fit that MS had "removed hardware acceleration" from GDI and that it made their apps terribly slower.. Which concerns me, because I think I read MS intended for Direct2D to replace GDI or something like that (that was the theory of the blog I read about GDI's performance being crippled)..

But to ask a specific question here... let's take Winforms (the standard GUI controls, etc that everything uses) - is that running off GDI? I guess part of my search is finding out where I truly want to "start" in terms of making my own GUI control... I did see a rather simple tutorial on extending a base class that was done in C/C++ (one of the two...) which I kind of understood. But it didn't really go into specifics about adding functionality to a Form/Control/ etc.. I'm also still trying to get the concept of Callbacks to "click" in my head.. I just don't really get how/what they are used for in the big picture. It's just an obscure bit of code syntax on the page to me, thus far..

I will try some more googling though... Frankly I think "Computer Science" is going to get far too vague a result, but Computer Vision might prove interesting so I will start there.

GDI and GDI+ are *software* abstraction layers - so they shouldn't, strictly speaking, according to Microsoft's own design guide, be doing things like utilising hardware features to make things go faster. This bypasses the HAL and can potentially lead to all sorts of problems at runtime as assumptions may be made about the particular configuration of a users computer which aren't true. They should use the HAL to ensure that the right dialogue are always undertaken. But of course this introduces another layer of software into the mix. Kind of a damned if you do, damned if you don't situation - and critics on both sides of the argument would be correct.

It was a simplification, and in truth Windows provides several different drawing libraries. GDI, GDI+, DirectX and there are numerous third party drawing libraries too OpenGL...

GDI doesn't just do one thing - it does lots of them. The link I put in my previous post is the complete description of all its many functions. But it provides functions for manipulating bitmaps, brushes, shapes, lines - all sorts. Oh - and fonts too of course.

I used a Microsoft Utility called Dependency Walker on my Purebasic installation. This tool examines a program or DLL file to determine what other libraries it refers too - and what those files refer too in turn. This is a *partial* section of the results - the whole output is far more detailed.

I've numbered some of the lines below and put an exclamation point after them to differentiate from the Dependency Walker output.

Here's a bit of what's going on.

1) Ok so I examined Purebasic.exe which is the IDE.
2) The exe uses a library called COMCTL32.DLL - this is the Windows Common Controls Library, and provides things like the buttons, combo boxes, edit controls, treeview controls.
3) COMCTL32.DLL directly calls GDI32.dll which is the GDI library.
4) COMCTL32 also uses a library called UXTHEME.DLL (User eXperience Theme - I think) on my computer to show controls with Windows XP Styling.
5) UXTHEME is also calling GDI32.
6) Another library, USER32.DLL, which handles other user interface stuff - also calls functions in GDI32.
7 and 8 ) At this point its getting a bit self referential - because GDI32 calls functions in USER32.

It goes on - I only included the first few lines to demonstrate - but I hope it proves conclusively two things:-
1) That GDI is actively involved.
2) That there is a complex software abstraction layer; the components of which are all helping each other to produce an harmonious final result.

If you have any of the Microsoft Visual Studio products you should have a copy of depends.exe on your computer to play with already. If not you can get it here http://www.dependencywalker.com/

Think of a phone call back. Someone calls you but you're out. So they leave a message on the answerphone (or with a colleague etc) to say "Hi its AAAA can you call me back please - my number is xxx xxx xxxx".

When you get the message you know that they have something that they want to talk to you about.

A callback procedure is similar (although I admit not identical). When you tell Windows about the callback procedure you are giving it a 'phone number' (the address of a procedure) to 'call' you 'back' on - to let you know that something has happened that you might want to know about.

When the operating system calls you back it 'leaves' a detailed message of what happened (the procedure's arguments). In this procedure you 'listen to the message' (examine the arguments), work out what that something was and take appropriate action (or not as the case may be).

Callback procedures have a couple of uses, depending upon exactly what sort of callback procedure you are referring to.

1) Events in the OS are asynchronous - the exact time the user will perform any particular action can't be predicted in advance. Sometimes it isn't a problem if the response to the action is delayed a bit. But if an event is time sensitive (it must be responded to quickly to be useful) - then a callback procedure provides a good way to handle this because the operating system can call it asynchronously regardless of what else might be occurring in your application.

2) If there are a variety of "objects" kicking around (and I'm using the term generally here, not Object in the sense of Object Orientated Programming) and they need to be handled in superficially similar but ultimately slightly different ways. You can register a callback procedure for each different type of object to say that 'when this general event happens to this object; this procedure knows what to do about it'.

For example, think about a water balloon and a football - they're both superficially round objects that you can kick. When you kick the football - you have to go after it to pick it up (or have a friend around to kick it back). However when you kick the water balloon - chances are you are going to have to dry your shoes off.

3) In Windows (I don't know if this applies to Linux too), you can modify the arguments of an event in a Callback procedure before it is handled by the OS itself, if you should feel the need, although this is an advanced subject and can wreak havoc if done carelessly.

Finally (you'll be glad to here).

1) I'm not sure that searching on "Computer Vision" is going to be too much help either - I suspect that you will get lots of references to computer visual recognition projects.

2) Have a look at this (PDF) document which srod wrote http://www.purecoder.net/Subclassing.zip
Its a guide to subclassing controls in PureBasic, which might be a place to start your own investigations.

3) If you really want to go it completely alone, search the forum for "custom control" or "custom gadget" - there are several extremely clever bods; not me sadly; who've done exactly that already and published notes on the subject.

4) @ codewalker - gosh!

You should try experimenting with an image from CreateImage(), an ImageGadget() and the 2d drawing commands from the help file. Especially DrawText(). All text on a computer is drawn in a similar fashion. Selected text isn't really special, it's just drawn with different background and foreground colors.

Thanks for the detailed posts. I really appreciate this info.

Trond - I'm beginning to understand that, for the most part..