pcoder

Close enough for me, because a larger size would lead to more hassle, and MS is aware of this.

Essentially I need to copy/paste MIME formats as defined in urlMon.h and others. I've seen a few clipboard readers which use GlobalSize(handle) as file size. The alternative would be having a correct reader for all possible file types, just for finding the file size. I believe Microsoft is aware of these and other challenges and has corrected globalSize(), but I have no proof.

Here is an excerpt from linked oldNewThing: With mistake I mean, globalSize() would be much useless without giving the requested size (clipboard content size). And I just wanted to know if anyone of the forum members got a larger size than requested, because I don't.

Thank you, initially I thought the same (as stated in MS docs), but so far I could not confirm that GlobalSize() returns a larger size. Did you also read the given link to oldnewthing which contains "bonus chatter"? And I cannot believe that MS made such a mistake but has not corrected this. In my use case, the clipboard format, used in getClipboardData(format), refers to a MIME type (a file in memory). The clipboard reader needs to save each received stream to a file, which is easy if the file size is known. But interpreting every data format (more than 20 different MIME types) to find the correct file size is very cumbersome. I just hope that globalSize() returns the same as heapSize() If the clipboard is used for a MIME type (file (png, svg, ...)), then the file size is not stored additionally (because this would break the MIME format). therefore I need globalSize() to give the correct filesize.

Has anyone seen the case of globalSize() returning more than the requested size? It would be much more useful to get the requested size (<= allocated size) to determine the clipboard data size, but unfortunately I've found contradicting statements about globalSize(). Pro allocated size: learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalsize stackoverflow.com/questions/22075754/how-do-i-determine-clipboard-data-size Pro requested size: devblogs.microsoft.com/oldnewthing/20120316-00/?p=8083 www.labri.fr/perso/betrema/winnt/heapmm.html www.joelonsoftware.com/2001/11/20/a-hard-drill-makes-an-easy-battle/

BTW, have you also measured the impact of type? single (CVTTSS2SI) vs double (CVTTSD2SI) No need for numbers, just wondering about the average difference :)

Ah yes, the documentation. Someone else found this too:)

CVTSS2SI vs. CVTTSS2SI: CVTTSS2SI (truncation (rounding toward 0)) does not use/need MXCSR.

COLRv1 was just an info shown in the file properties dialog. The glyph rendering looks vector based and has color gradients, so SVG or COLRv1. Format-selection is for lower-level handling, but I use only RenderTarget.drawTextLayout() with D2D1_DRAW_TEXT_OPTIONS_ENABLE_COLOR_FONT. It would be useful here (also for end-users) if DirectWrite would offer a parameter to specify a preferred format. If possible I try to avoid lower-level handling, even more code according to the preview

Most common fonts are acceptable, but even "Noto Color Emoji" (2.038) can be very slow on certain systems. The file description displays COLRv1, but I don't know if DirectWrite actually uses this format.

Answering to myself: This is OK for (TDirect2DCanvas.RenderTarget.dpi = 96) only, ie (pixels = DIPs). dpi 96 (regardless of screen dpi and font.dpi) allows clients to pass pixel coordinates to all Direct2D-functions which want DIPs. This is GDI-compatible, so clients must provide final pixel values (dependent on screen (or other) DPI).

Yes, in most cases more than sufficient.

Each textline needs up to 2 seconds :), varies on whether DirectWrite has found a way to cache something. I also have found that DirectWrite textdraw to bitmap DC is slower than DirectWrite textdraw to window DC. But I'm still happy with the progressive display now. And users have the option to select a different font:) The challenge (I should have mentioned it earlier) was, the user clicks a button to generate a different image on display. Thus a waiting time between button click and resulting display is impossible to avoid, regardless of internal concept.

Thanks for all! I will use a bitmap and draw into it whenever I have a time slot. The main problem is a real slow color-font (text draw 100+ times slower than with other color-fonts). I will also try distribution over several WM_Paint (each displays whole (but possibly unfinished) bitmap)), will see... (should look better than freeze). As Remy said, the framework is not prepared for this, so I will extend the wmPaint method to trigger the next paint. Initial tests have shown that this works. procedure TmyControl.WMPaint(var Message: TWMPaint); begin wantMorePaintTime := false; inherited; if wantMorePaintTime then postMessage( handle, iwm_wantPaintTime, 0, 0); // handler calls self.invalidate; end;

Sometimes my draw in OnPaint (WM_Paint) is very slow (kind of UI freezing). Now I would prefer to exit the paint handler earlier (based on time measurement (getTickCount)) and continue the draw in subsequent OnPaint events (like progressive drawing). Is that possible under Windows? And how can I trigger the paint events?