Index
> Windows > gdi and directdraw, font cache |
| Author |
|
|
vivik 09 Jun 2018, 14:56
I'm making a text editor, in directdraw, I hope it will be faster than gdi, (and I'm planning to make a game anyway). Yet I'm still using gdi for drawing text, for fonts. I'm doing ->GetDC(), then DrawTextW (though maybe I should be using TextOut), then ->ReleaseDC().
What do you think, will it worth it to cache every character in a separate directdraw surface? Just so that I have to call gdi as rarely as possible, and copy characters from that surface instead? Or DrawTextW is fast enough? I will probably use monospace font, I'm used to it anyway, and I don't have to remember width of every individual character. Yet I want asian characters to be bigger, since they have more detail each. This means, I will draw latin letters on a grid of one size, and asian on a grid of a bigger size. So, two separate font caches for latin and asian. Looks like gdi already has some sort of caching for font: http://download.sr-support.com/dispdoc/graphics_using_gdi.html >Drawing of fonts may be slower when a character is drawn for the first time in a new font. Also on speed of text drawing: https://theartofdev.com/2013/08/12/the-wonders-of-text-rendering-and-gdi/ |
|||
09 Jun 2018, 14:56 |
|
|
vivik 11 Jun 2018, 15:26
Hm.
Code: //int dx[2]; int dx; int fit; SIZE the_size; GetTextExtentExPointW(dc, L"WWWWWWWW", 8, -1, &fit, &dx, &the_size); Docs https://msdn.microsoft.com/en-us/library/windows/desktop/dd144935(v=vs.85).aspx say that alpDx is a pointer to an array, yet my visual studio says it's a LPINT. Maybe I should edit headers? I can see that it modifies more memory than it should. This is what headers contain: Code: WINGDIAPI BOOL APIENTRY GetTextExtentExPointW( __in HDC hdc, __in_ecount(cchString) LPCWSTR lpszString, __in int cchString, __in int nMaxExtent, __out_opt LPINT lpnFit, __out_ecount_part_opt (cchString, *lpnFit) LPINT lpnDx, __out LPSIZE lpSize ); Edit: nevermind Code: GetTextExtentExPointW(dc, L"WWWWWWWW", 8, -1, &fit, &dx[0], &the_size); |
|||
|
11 Jun 2018, 15:26 |
|
|
revolution 12 Jun 2018, 07:28
vivik wrote: 0x0044005c,  |
|||
|
12 Jun 2018, 07:28 |
|
|
vivik 12 Jun 2018, 14:22
I'd watch that movie.
Didn't check return value, it was zero, the function was falling. My head doesn't work. Hm, fails even if I'll change "Courier New" to "MS PGothic" and DEFAULT_CHARSET to SHIFTJIS_CHARSET in CreateFont. |
|||
|
12 Jun 2018, 14:22 |
|
|
vivik 12 Jun 2018, 16:15
This worked though.
ABC abc; GetCharABCWidthsW(dc, L'薔', L'薔', &abc); abc.abcA == 0 abc.abcB == 13 abc.abcA == 1 |
|||
|
12 Jun 2018, 16:15 |
|
|
vivik 12 Jun 2018, 18:45
Something is wrong. I'm told that L'薔' and L'l' have the same width of 7, yet asian character is obliviously wider when printed.
Code: ABC abc; GetCharABCWidthsW(dc, L'薔', L'薔', &abc); GetCharABCWidthsW(dc, L'l', L'l', &abc); Code: ExtTextOutW(dc, 0, 0, 0, //fuOptions 0, //lprc L"薔薇薔薇薔薇", 6, 0 //lpDx ); ExtTextOutW(dc, 0, 15, 0, //fuOptions 0, //lprc L"sususu", 6, 0 //lpDx ); Edit: that's if I specify DEFAULT_CHARSET, with SHIFTJIS_CHARSET 薔 is 14 and l is 2 |
|||
|
12 Jun 2018, 18:45 |
|
|
tthsqe 12 Jun 2018, 22:47
Hmm interesting. I am making a 2d text editor and simply copying from prerendered bitmaps. That obviouly doesnt give subpixel rendering...
|
|||
|
12 Jun 2018, 22:47 |
|
|
vivik 16 Jun 2018, 06:59
res = GetTextExtentExPointW(dc, L"薔薇薔薇薔薇薔薇", 8, 0x1000, &fit, &dx[0], &the_size);
This worked. Notice 0x1000 instead of -1. So, for font with height 14, kanji has width 14 and latin has width 7. |
|||
|
16 Jun 2018, 06:59 |
|
< Last Thread | Next Thread > |
Forum Rules:
|