Discussion:
Exception in Editor::RefreshPixMaps() in 3.0.1 d2d
(too old to reply)
Greg
2011-11-17 14:07:31 UTC
Permalink
I am running in VS2010 with MFC. I have a dialog in which I embed a
Scintilla edit control. This has worked for years with no problem and
still does if I don't use SetTechnology(SC_TECHNOLOGY_DIRECTWRITE). If
I do use d2d, I was getting the dreaded "The activation context being
deactivated is not the same..." message. This usually indicates that
an exception was being generated somewhere. Turning on all Win32 first
chance exceptions reveals that the call:
pixmapSelPattern->InitPixMap(patternSize, patternSize,
surfaceWindow, wMain.GetID());
line 3332 in Editor.cxx is causing an exception in
CreateCompatibleRenderTarget() (d2d1.h line 3338).
First-chance exception at 0x5b3e446c (SciLexer.dll) in SONVIEW.exe:
0xC0000005: Access violation reading location 0xfeeeff1e.
The exception address is 0xfeeefeee+0x30. It occurs because of edx =
[this], then [edx] is 0xfeeefeee, which suggests to me that we are
using something that has been freed. It appears that the something is
the virtual function table.

3338: return CreateCompatibleRenderTarget(&desiredSize,
NULL, NULL, D2D1_COMPATIBLE_RENDER_TARGET_OPTIONS_NONE,
bitmapRenderTarget);
5B3E4453 8B F4 mov esi,esp
5B3E4455 8B 45 10 mov eax,dword ptr
[bitmapRenderTarget]
5B3E4458 50 push eax
5B3E4459 6A 00 push 0
5B3E445B 6A 00 push 0
5B3E445D 6A 00 push 0
5B3E445F 8D 4D 08 lea ecx,[desiredSize]
5B3E4462 51 push ecx
5B3E4463 8B 55 F8 mov edx,dword ptr [this]
5B3E4466 8B 02 mov eax,dword ptr [edx]
5B3E4468 8B 4D F8 mov ecx,dword ptr [this]
5B3E446B 51 push ecx
5B3E446C 8B 50 30 mov edx,dword ptr [eax+30h]
<=====exception
5B3E446F FF D2 call edx
5B3E4471 3B F4 cmp esi,esp
5B3E4473 E8 1A 0C F8 FF call @ILT+16525(__RTC_CheckEsp)
(5B365092h)

Chasing this backwards, we come in at
ScintillaWin::SWndProc(hWnd=0xf0456, iMessage=0x0f =WM_PAINT,
wParam=0, lParam=0);
The hWnd is turned into a Window pointer sci for which sci-
pRenderTarget == NULL, which is, I suspect, the problem. This means
that ScintillaWin::EnsureRenderTarget() is called, which calls
pD2DFactory->CreateHwndRenderTarget(), which returns 0, and the
__vfptr is set. OK so far.

AutoSurface surfaceWindow(pRenderTarget, this);
happens next, and the surfaceWIndow has a pRenderTarget with a __vfptr
that is OK.

Editor::Paint() gets called (surfaceWindow is still OK), which calls
AllocateGraphics(), which does nothing in this case as all the pixmaps
have values.

pixmapLine is then released. all is still OK

RefreshStyleData() is called which creates a surface and destroys it.
This causes *surfaceWindow to have pRenderTarget with _vfptr set to
0xfeeefeee.

Then RefreshPixMaps(surfaceWindow) is called, but as surfaceWIndow,
pRenderTarget has a __vfptr set to 0xfeeefeee we are in crashlands.

I regret that I do not understand enough of what is going on here to
suggest a fix... It appears that the destructor of the AutoSurface
used in Editro::RefreshStyleData() is causing the problem, but of
course, it could be that I have screwed something up in my code.
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-18 00:27:12 UTC
Permalink
... Turning on all Win32 first
               pixmapSelPattern->InitPixMap(patternSize, patternSize,
surfaceWindow, wMain.GetID());
line 3332 in Editor.cxx is causing an exception in
CreateCompatibleRenderTarget() (d2d1.h line 3338).
0xC0000005: Access violation reading location 0xfeeeff1e.
I'm not seeing this now although there were some similar problems
while writing the Direct2D code. There should only ever be a single
render target created at any time for a HWND. Check that there is no
reentrance creating a second HWND render target. The state of
bufferedDraw could influence the execution path.
...
RefreshStyleData() is called which creates a surface and destroys it.
This causes *surfaceWindow to have pRenderTarget with _vfptr set to
0xfeeefeee.
The surface created in RefreshStyleData is only for determining
font metrics and I don't think it ever has a valid render target. It
should not be associated with the render target for the window.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-18 12:07:46 UTC
Permalink
Having spent quite a bit of time stepping around through this, I don't
really see what I can be doing wrong to cause this. As I said, I have
a Scintilla control in a dialog and I create the control, enable D2D
and do some setup, then this problem happens in the WM_PAINT call, so
I don't see how I can make anything recursive there. The change to the
Editor::Paint() surfaceWindow->pRenderTarget...__vfptr occurs when the
AutoSurface in RefreshStyleData is deleted. Could this be some obscure
auto pointer bug? (your comments say something about auto pointers in
this area). I don't have the time right now to get my head around
exactly what is going on here, so I may just have to disable D2D.

What is odd is that this dialog is used in several contexts, and it
fails in all but one. These contexts relate to the type of text
document that is displayed (script, pure text, and other file types).
The one that does not fail is not significantly different from the
others... it has more code for helping a programmer write scripts, and
a more complex lexer, but nothing to do with drawing.

Just to be explicit about what I see: after the AutoSurface in
RefreshStyleData is destroyed, Editor::Paint() surfaceWindow shows in
the debugger as:
[SurfaceD2D}
Surface ...
unicodeMode false
x 0
y 0
codePage 0
pRenderTarget 0x0302eb30
ID2D1Resource ...
IUnknown ...
__vfptr 0xfeeefeee (this was a previously a sensible
value)
ownRenderTarget false
clipsActive 0
...
__vfptr 0x59383aa4 const SurfaceD2D::'vftable'

So it is the associated render target that seems to have been
unloaded.
... Turning on all Win32 first
               pixmapSelPattern->InitPixMap(patternSize, patternSize,
surfaceWindow, wMain.GetID());
line 3332 in Editor.cxx is causing an exception in
CreateCompatibleRenderTarget() (d2d1.h line 3338).
0xC0000005: Access violation reading location 0xfeeeff1e.
   I'm not seeing this now although there were some similar problems
while writing the Direct2D code. There should only ever be a single
render target created at any time for a HWND. Check that there is no
reentrance creating a second HWND render target. The state of
bufferedDraw could influence the execution path.
...
RefreshStyleData() is called which creates a surface and destroys it.
This causes *surfaceWindow to have pRenderTarget with _vfptr set to
0xfeeefeee.
   The surface created in RefreshStyleData is only for determining
font metrics and I don't think it ever has a valid render target. It
should not be associated with the render target for the window.
   Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-18 15:27:40 UTC
Permalink
I have done some more debugging and I was wrong in saying that it was
the AutoSurface destructor that was causing the problem. The trouble
happens in:

RefreshStyleData() which calls
SetScrollbars() which calls
ModifyScrollBars() which calls
SetScrollInfo(SB_VERT, &sci, TRUE); which calls
::SetScrollInfo(MainHWND(), nBar=1, lpsi,
bRedraw=true);

And the SetScrollInfo(...) cause the 0xfeeefeee to appear.

Perhaps the vertical scroll bar should NOT be told to redraw?
This also explains the difference between my situations which work and
those that do not. The one case that worked did not have a vertical
scroll bar in the window, but the ones that failed all had a vertical
scroll bar.

I am not sure what more I can do to debug this further as I don't
really understand what is going on here. What is happening does not
seem to fit with your description of RefreshStyleData() as this code
is clearly attempting to cause some repainting, perhaps this is what
you meant by recursive calls.
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-18 15:56:05 UTC
Permalink
I can also report that simple-mindedly changing the TRUE to FALSE in
SetScrollInfo() does not make any difference (which is not surprising
given the cause of the problem). The problem is that setting the
scroll bar information cause WM_WINDOWPOSCHANGING, then
WM_WINDOWPOSCHANGED, then WM_SIZE. WM_SIZE calls DropRenderTarget(),
which destroys the render target, leading to crashes.

If you can suggest a fix for this I would be happy to try it out. I am
somewhat surprised that no-one else has noticed this... maybe it is
unusual to set the text in a window so a vertical scroll is needed,
causing the window to resize when you call RefreshStyleDefault().
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-19 00:18:08 UTC
Permalink
Post by Greg
I can also report that simple-mindedly changing the TRUE to FALSE in
SetScrollInfo() does not make any difference (which is not surprising
given the cause of the problem). The problem is that setting the
scroll bar information cause WM_WINDOWPOSCHANGING, then
WM_WINDOWPOSCHANGED, then WM_SIZE. WM_SIZE calls DropRenderTarget(),
which destroys the render target, leading to crashes.
Thanks for tracking that down. I'll investigate further.
Post by Greg
If you can suggest a fix for this I would be happy to try it out. I am
somewhat surprised that no-one else has noticed this... maybe it is
unusual to set the text in a window so a vertical scroll is needed,
causing the window to resize when you call RefreshStyleDefault().
I think its likely that in most cases the vertical scroll
appearance is decided on a different path.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-19 00:46:10 UTC
Permalink
In SciTE, the WM_SIZE seems to be occurring when text is inserted
causing a modification notification to go to the view or when the
document is set in the view. Neither of these are caused by painting.

In SetScrollBars, the change to the scroll bars is seen in the
modified variable which than causes AbandonPaint(). Possibly, there
needs to be a new check for (paintState == paintAbandoned) inside
paint and a return before the crashing code.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-19 18:34:51 UTC
Permalink
I can't try this right now as my home machine runs XP, so this will
have to wait until Monday when i can run on Windows 7 at work.
Further, I'll need a bit more guidance about what to change as I
haven't got my head around what you are doing here and what paintState
is about.

My diagnosis of the problem is that setting the scroll bar info is
causing the scroll bar to exist, which is causing size changes, which
is releasing the object being used to do the rendering... As this is a
complex interaction it plainly needs to be understood before messing
with it... This all happens because RefreshStyleDefault() does not
expect to make any changes that will invalidate the renderer.

I think what I am saying is "please tell me what to change and I'll
try this in a known failing situation and report back".

Have you managed to reproduce the problem? Unfortunately, the my code
is in a large and complex application. However, here is the
OnInitDialog code that sets up a scintilla control which then dies in
the WM_PAINT that follows the OnInitDialog. (this is the dialog a user
sees when they want to configure scintilla).

Explanations: CHelpDialog is a descendent of CDialog with useful
addtions. m_Edit is my wrapper around Scintilla that has all the
messages as member functions plus a few more useful things for folding
and the like. m_pWork is an object that handles the the differences
between the different uses I make of scintilla (script editor, a
separate machine code-like editor and a plain text editor for log
files and user text files) and I use it to apply styles and folding
and set lexers for the scintilla control. The example text has
sufficient lines that we need a vertical scroller in the crashing
cases.


BOOL CTxtSetupDlg::OnInitDialog()
{
CHelpDialog::OnInitDialog();
... lots of omitted setup code...

// Find position for the edit control to display the example text
and create it
CWnd *pWnd = GetDlgItem(DLG_TXT_SETUP_EDITOR); // get the window
ASSERT(pWnd);
CRect rEdit;
pWnd->GetWindowRect(&rEdit); // get in screen co-ords
ScreenToClient(&rEdit); // local co-ords
m_Edit.Create(WS_CHILD|WS_VISIBLE|WS_TABSTOP, rEdit, this, 0);
m_Edit.SetTechnology(SC_TECHNOLOGY_DIRECTWRITE);
m_Edit.SetFontQuality(SC_EFF_QUALITY_LCD_OPTIMIZED);// and best
quality font

CString csExample;
m_pWork->GetExampleText(csExample); // Get some sample text to
edit
m_Edit.SetText(csExample); // give user something to gawp
at
m_pWork->ApplyAll(m_Edit); // apply all except folding
m_pWork->ApplyFolding(m_Edit); // set the initial folding
state
...lots more omitted code ...

return TRUE;
}
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-19 21:49:58 UTC
Permalink
Post by Greg
Further, I'll need a bit more guidance about what to change as I
haven't got my head around what you are doing here and what paintState
is about.
Scintilla does quite a bit of setup work in the painting code,
including ensuring that all visible text has been styled. If this
setup causes a change in state that means the current painting will
not be accurate then the painting is abandoned, execution returns from
Paint and a redraw of the whole window is queued. A common cause of
abandoning paint is that styling flowed out of the repaint region
when, for example, starting a multi-line comment requires the rest of
the window to be redrawn.

Code called by Paint indicates that it has detected that this
painting will be unsuccessful by setting paintState to paintAbandoned.
Post by Greg
My diagnosis of the problem is that setting the scroll bar info is
causing the scroll bar to exist, which is causing size changes, which
is releasing the object being used to do the rendering... As this is a
complex interaction it plainly needs to be understood before messing
with it... This all happens because RefreshStyleDefault() does not
expect to make any changes that will invalidate the renderer.
Before Direct2D, it was not possible to invalidate the renderer as
the DC (or equivalent on other platforms) does not depend on the
window size whereas Direct2D has allocated a pixmap of the same size
as the window to draw into.

Maybe invalidating the renderer could be deferred until after the
paint has finished. Although its fairly pointless except to avoid the
crash.
Post by Greg
I think what I am saying is "please tell me what to change and I'll
try this in a known failing situation and report back".
Find where your crash is occurring and insert before:

if (paintState == paintAbandoned)
return;
Post by Greg
Have you managed to reproduce the problem?
No, I'm trying to think of how your sequence could cause the bug.
Maybe if there was a difference in the heights of your chosen fonts
and a default value and your example text is just long enough to
switch between fitting and not with that difference.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-20 11:55:56 UTC
Permalink
OK. I think that you are saying that if the Set Scroll Info causes a
change, I should set the paintState to abandoned. I will try this on
Monday.

The basic problem is that you are doing stuff in WM_PAINT that can
cause a size and recursive paint, which is unusual, not to say
immoral, illegal and fattening. I now begin to understand why you need
the paintState... I just feels a bit messy to get these recursive
messages... but I guess you want to defer all the recalculations until
you actually get a paint call...
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-21 10:39:03 UTC
Permalink
The minimum set of changes needed to display my dialog without a crash
in D2D mode are:

1) Editor::Paint(...) around line 3489
pixmapLine->Release();
RefreshStyleData(); // this call may resize window...
if (paintState == paintAbandoned) // ...which destroys D2D
pixmap
return;
RefreshPixMaps(surfaceWindow);

2) ScintillaWin::WndPaint(...) around line 583
Paint(surfaceWindow, rcPaint);
surfaceWindow->Release();
if (pRenderTarget){ // can be 0 if paintAbandoned
HRESULT hr = pRenderTarget->EndDraw();
if (hr == D2DERR_RECREATE_TARGET) {
DropRenderTarget();
}
}

3) Editor::SetScrollBars() around line 3926
bool modified = ModifyScrollBars(nMax + nPage - 1, nPage);
if (modified) {
DwellEnd(true);
paintState = paintAbandoned; // for D2D case
}

The problem with this is that any change to the scroll bars will
result in no paint, which cannot be correct. I guess you could set a
flag in the WM_SIZE to note that the pixmap has been recreated. The
flag would be cleared when the surface window was created in WndPaint.

Instead of 3) the following works, and is better as it will not
abandon ship unless we really must:

4) ScintillaWin::WndProc(...) around line 749
case WM_SIZE: {
if (paintState != notPainting)
paintState = paintAbandoned;
DropRenderTarget();
//Platform::DebugPrintf("Scintilla WM_SIZE %d %d\n",
LoWord(lParam), HiWord(lParam));
ChangeSize();
}
break;

RefreshStyleData() is called 10 times. SetScrollBars() is called a lot
more times. I have not investigated how many of these can occur inside
Paint(), needing further tests for paintAbandoned.

If you need to reproduce this, I guess I can attempt to build the
minimum application to demonstrate all of this and send it to you. It
may take a while to do...
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-22 10:55:11 UTC
Permalink
1, 2, 4 appears OK. The NULL detection could be put in
ScintillaWin::ModifyScrollBars but that's not much different. An
exception could be thrown in ModifyScrollBars although that may need
calling code to be made exception safe.

Another possibility is to allow a Surface to be set to 'invalid'
and to then check this after operations which could cause size
changes. The surface allocated in WndPaint would have to be made more
widely visible so it could be invalidated in WM_SIZE.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-22 12:56:44 UTC
Permalink
Would it be possible to just have one surface and one rendering object
that is used rather than having temporary ones that effectively take a
copy of the rendering object, which is where the problems come from? I
guess this would mean recreating the renderer in WM_SIZE if
paintState != notPainting. We could then likely get rid of 1) and 2),
but at the cost of work that would impact all renderers; the result
should be more robust and might provide future proofing on all
platforms. However, I don't have your experience and insight into the
other platforms, so this might be a stupid idea.

If you decide to go with 1,2,4 mods, some of the code can be removed
for non D2D cases. I have not noticed any display problems with with
the modifications in place, but as I only get the problem in
restricted circumstances this is not surprising.
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-23 01:19:15 UTC
Permalink
Post by Greg
Would it be possible to just have one surface and one rendering object
that is used rather than having temporary ones that effectively take a
copy of the rendering object, which is where the problems come from?
Direct2D is unusual in having a long term drawable - most APIs
provide a temporary object for drawing and holding onto that would
fail. It would be possible to have a different structure for handling
Direct2D than GDI but that difference may then manifest in multiple
places.
Post by Greg
If you decide to go with 1,2,4 mods, some of the code can be removed
for non D2D cases. I have not noticed any display problems with with
the modifications in place, but as I only get the problem in
restricted circumstances this is not surprising.
Its likely the crash could be prevented in your example by calling
an API that forces realization of resources before the paint. Perhaps
SCI_TEXTWIDTH(0, "")

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-23 11:46:34 UTC
Permalink
   Its likely the crash could be prevented in your example by calling
an API that forces realization of resources before the paint. Perhaps
SCI_TEXTWIDTH(0, "")
Yes; this seems to work around the problem. BUT it still leaves a bug
waiting to happen depending on the sequence of calls and leaves me
with a queasy feeling that my application might crash one day. Surely,
if there is a route by which things can fail, then they will (usually
at the most expensive/embarrasing moment). It seems that in D2D mode
there will be a crash if it is possible to get into a state where a
vertical or horizontal scoll bar will appear that is detected in the
Paint call.

I notice that in Editor::Paint() there is already code that sets
paintAbandonedByStyling if paintState == paintAbandoned, so you must
already have had issues with RefreshStyleData() causing problems... so
I guess there are other routes where similar effects can happen and if
any of them cause size changes there will be a crash.

If you don't want to detect WM_SIZE being called while painting, then
this effect needs documenting and a SCI_FINALISESETUP message or
similar should be added... alternatively/as well we can put an ASSERT
in WM_SIZE and tell people in it to report how they got there and
explain how to avoid it.

It might be better to reorganise things a bit so that the:

if (paintState != notPainting)
paintState = paintAbandoned;

can go in the DropRenderTarget() code, which localises it to D2D
only... and also makes ure that any place where we can kill the target
is detected. In this case care needs to be taken setting where
paintState is set and cleared as this would currently cause problems.
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-24 12:16:38 UTC
Permalink
Post by Greg
Yes; this seems to work around the problem. BUT it still leaves a bug
waiting to happen depending on the sequence of calls and leaves me
with a queasy feeling that my application might crash one day.
I wasn't trying to say this would be a solution, just trying to
investigate how likely it was to occur and whether something more
complex was happening. If this problem only ever occurs once then it
isn't a performance problem. If it recurs often then abandoning paint
isn't a good solution and refreshing the style through another method
like a prepaint message may be better.
Post by Greg
I notice that in Editor::Paint() there is already code that sets
paintAbandonedByStyling if paintState == paintAbandoned, so you must
already have had issues with RefreshStyleData() causing problems...
'Styling' here refers to lexing which is the most common cause of
abandoning paint.
Post by Greg
If you don't want to detect WM_SIZE being called while painting, then
this effect needs documenting and a SCI_FINALISESETUP message or
similar should be added... alternatively/as well we can put an ASSERT
in WM_SIZE and tell people in it to report how they got there and
explain how to avoid it.
I do want to detect this situation and handle it automatically.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-24 15:41:19 UTC
Permalink
I am certain that this is not a performance issue; if it were (i.e. it
was happening often), anyone who enabled D2D would be hitting it.
However, it may be that very few people have enabled D2D yet as it is
not the default and the effect of using it is not dramatic. From some
simple timings of repainting a screen of text, D2D seems to be
slightly slower to render (a few percent). Speed is difficult to
compare fairly as the D2D layout at 10 pt of the font I used was
significantly larger than the non-D2D version of the same thing and I
had to reduce the D2D font size to end up with more comparable screen
update areas. The D2D rendering looks slightly easier to read at small
font sizes.

Having put in your workaround SCI_TEXTWIDTH(0, "") with a breakpoint
set in the test in WM_PAINT for interrupting paint, I do not get any
hits. I will leave a break point in during testing to see if I can
provoke this any other way.
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-25 22:51:36 UTC
Permalink
Post by Greg
Speed is difficult to
compare fairly as the D2D layout at 10 pt of the font I used was
significantly larger than the non-D2D version of the same thing and I
had to reduce the D2D font size to end up with more comparable screen
update areas. The D2D rendering looks slightly easier to read at small
font sizes.
DirectWrite supports fractional font sizes
(SCI_STYLESETSIZEFRACTIONAL) so I use a set of styles that have
similar sizes for both:
font.base=font:Verdana,size:9.7
font.comment=font:Segoe UI,size:8.9,italics
font.monospace=font:Consolas,size:8.9

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-26 09:01:49 UTC
Permalink
Since this is only occurring at initial setup, performance doesn't
appear to be an issue. That allows this to be fixed by deferring
dropping the render target until the next paint when it will be
recreated. The benefit to this is that if there are any other ways in
which a resize can be triggered within the paint then there won't be a
crash. The additional work performed on this abandoned paint should be
small. This allows the modification to be completely handled inside
the ScintillaWin code so other platforms don't have to consider this
behaviour.

A change set for this was committed as
http://scintilla.hg.sourceforge.net/hgweb/scintilla/scintilla/rev/c0217fb3729e

Also available from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-26 15:21:46 UTC
Permalink
Thanks for the patch. I'll try this out next week and let you know if
there are any problems.
Greg
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Greg
2011-11-29 10:10:40 UTC
Permalink
The patch stops the crash, thankyou.

I note that the new SCI_COUNTCHARACTERS is included in the .iface file
out of numerical order. I only mention it as most items are in order
and this may not be what you intended.
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Neil Hodgson
2011-11-29 11:15:12 UTC
Permalink
The patch stops the crash, thank you.
Good.
I note that the new SCI_COUNTCHARACTERS is included in the .iface file
out of numerical order. I only mention it as most items are in order
and this may not be what you intended.
The ordering sometimes goes roughly by functional area and
CountCharacters is related to GetColumn which precedes it. Order is a
bit haphazard.

Neil
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-***@googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Loading...