March 2001 - Wine-Devel - list.winehq.org

Re: [PATCH] HOOK_CallHook

by David Elliott

Francois Jacques wrote: > > > > > IMHO, performing code review of the whole tree for missing volatile > keywords > > > would be a waste of time compared to do it on a case by case basis. > Simply > > > keep in mind that those bugs may happen - especially with "aggressive" > > > compilers such as gcc 2.96. If a bug didn't happen with the previous > > > compiler and does show up with the latest release, it might be a good > > > candidate. > > > > But the point is, this is *not* a Wine bug that was just exposed by a > > new compiler -- this is a compiler bug, plain and simple. > > Did I write it was a WINE bug? No. It is very clear for me that it *is* a > compiler issue. > > I had three choices > > a) find a workaround and have people comment on it; > b) disable the optimize phase for gcc 2.96 and have the whole community on > my back; > c) fix gcc. > > I went for the easy one. > > > Making these variables 'volatile' is not required at all -- 'volatile' > > tells the compiler that the variables might be changed behind the > > compiler's back, e.g. due to being asynchroneously modified by a signal > > handler or something like that. In this particular case, however, the > > variables are not only not changed behind the compiler's back, they > > are *never* changed at all! > > 100% agree. Again, it's a quick-yet-efficient workaround to the compiler > problem that just happened to work. While volatile is for variables that are > modified by external factors, it was a good way to prevent all the > optimization - which was just what I wanted. > To be honest, I didn't read the patch and simply assumed this was a simple case of forgetting to add volatile and getting bitten by a compiler that optimizes more agressively. Either way it still is a valid point to be concerned about not only compiler bugs but also new compiler features. > > > Instead of circumventing the compiler bug in this particular case, > > it might be preferable to find out which optimization phase contains > > the bug, and write a configure check that switches that phase off > > if it detects the bug (like we did with the 2.95.2 strength-reduce bug). > > We'll do some research on the optimization phase. Once we found it, can > anybody help us with that autoconf kungfu? > That would be a good idea. Of course I don't think the volatile keyword in this case is hurting anything except maybe speed (negligble). Hopefully this can get fixed soon in gcc. Looking at the gcc project page, it seems that 3.0 is very close to be done. -Dave

March 30, 2001

Re: [PATCH] HOOK_CallHook

by Ulrich Weigand

> Did I write it was a WINE bug? No. It is very clear for me that it *is* a > compiler issue. OK, I must have misunderstood you then. Sorry ... > > Instead of circumventing the compiler bug in this particular case, > > it might be preferable to find out which optimization phase contains > > the bug, and write a configure check that switches that phase off > > if it detects the bug (like we did with the 2.95.2 strength-reduce bug). > > We'll do some research on the optimization phase. Once we found it, can > anybody help us with that autoconf kungfu? I've managed to reduce the problem to a simple testcase, which is appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... Culprit *appears* to be the global common subexpression elimination, although this is not quite definite. I haven't tracked the problem down yet. However, when switching off GCSE (-fno-gcse), correct code is produced. I'm not sure I'd like to do a complete Wine build without GCSE though; this might significantly reduce code quality ... I'll write a configure check to switch off gcse, using the testcase below. We should probably contact RedHat (I think Jacub Jelinek handles 2.96 bugs ...) to confirm that GCSE is really at fault. Bye, Ulrich void clobber(int *); void compare(int, int); void use(int); int global; void test(int trigger, int param) { int data = trigger? global : 0; int orig_param = param; clobber(&param); compare(orig_param, param); use(data); } void clobber(int *param) { (*param)++; } void compare(int orig_param, int param) { if (orig_param != param) printf( "PASS\n" ); else printf( "FAIL\n" ); } void use(int data) { } int main(void) { test(0, 0); } -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 29, 2001

Re: controls/edit.c

by lawson_whitney＠juno.com

On Thu, 29 Mar 2001, Ulrich Czekalla wrote: > I forgot to plug a region leak before I sent the patch in. I have > attached an updated patch. > > /Ulrich > Good day! This message comes to you from Juno-2.0.11 without benefit of junopine: I am composing it with Juno's GUI composer using the new edit.c. Much less flicker. I still can't answer a letter this way: Juno chokes on a SendMessageCallback as soon as it gets anything in its inbox, but that is nothing to do with edit.c It is hot and heavy with ads now and I get some sluggishness because I am contending with the ad engine for the 47 bogoMIPS of the mighty p-120, but really it seems much better. I still don't like GUI though, and Juno might get annoyed if I delete all its ads, which I would have to do to really use this composer, so I will go back to Pine now, but it does seem much better nor it was. Lawson ---cut here Well, not quite without junopine. I hit alt-s meaning to send it, and saved it to the draft folder instead, and tripped on another SendMessageCallback trying to get it out, but I did compose it with a GUI editor. The first patch moved the cursor for each character of the password, but showed no character, but with the revised patch I see the xxxx strikover I am accustomed to see. I think it is an improvement, but I am hardly a GUI guru. First soldier into the minefield, maybe, and still alive. Regards, Lawson ---cut here. Really. "The Rest is Spam." ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 29, 2001

Re: [PATCH] HOOK_CallHook

by Francois Jacques

> > > IMHO, performing code review of the whole tree for missing volatile keywords > > would be a waste of time compared to do it on a case by case basis. Simply > > keep in mind that those bugs may happen - especially with "aggressive" > > compilers such as gcc 2.96. If a bug didn't happen with the previous > > compiler and does show up with the latest release, it might be a good > > candidate. > > But the point is, this is *not* a Wine bug that was just exposed by a > new compiler -- this is a compiler bug, plain and simple. Did I write it was a WINE bug? No. It is very clear for me that it *is* a compiler issue. I had three choices a) find a workaround and have people comment on it; b) disable the optimize phase for gcc 2.96 and have the whole community on my back; c) fix gcc. I went for the easy one. > Making these variables 'volatile' is not required at all -- 'volatile' > tells the compiler that the variables might be changed behind the > compiler's back, e.g. due to being asynchroneously modified by a signal > handler or something like that. In this particular case, however, the > variables are not only not changed behind the compiler's back, they > are *never* changed at all! 100% agree. Again, it's a quick-yet-efficient workaround to the compiler problem that just happened to work. While volatile is for variables that are modified by external factors, it was a good way to prevent all the optimization - which was just what I wanted. > Instead of circumventing the compiler bug in this particular case, > it might be preferable to find out which optimization phase contains > the bug, and write a configure check that switches that phase off > if it detects the bug (like we did with the 2.95.2 strength-reduce bug). We'll do some research on the optimization phase. Once we found it, can anybody help us with that autoconf kungfu? Ciao! Francois

March 29, 2001

Re: [PATCH] HOOK_CallHook

by Ulrich Weigand

> IMHO, performing code review of the whole tree for missing volatile keywords > would be a waste of time compared to do it on a case by case basis. Simply > keep in mind that those bugs may happen - especially with "aggressive" > compilers such as gcc 2.96. If a bug didn't happen with the previous > compiler and does show up with the latest release, it might be a good > candidate. But the point is, this is *not* a Wine bug that was just exposed by a new compiler -- this is a compiler bug, plain and simple. Making these variables 'volatile' is not required at all -- 'volatile' tells the compiler that the variables might be changed behind the compiler's back, e.g. due to being asynchroneously modified by a signal handler or something like that. In this particular case, however, the variables are not only not changed behind the compiler's back, they are *never* changed at all! If the compiler generates incorrect code here, this is just a bug, probably somewhere in the common subexpression elimination (or maybe reload) code. Now if the compiler has this bug, it might manifest itself also at different places -- which we *cannot* find by a code review, as the code itself is completely correct ... Instead of circumventing the compiler bug in this particular case, it might be preferable to find out which optimization phase contains the bug, and write a configure check that switches that phase off if it detects the bug (like we did with the 2.95.2 strength-reduce bug). Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 29, 2001

Re: [PATCH] HOOK_CallHook

by Francois Jacques

> This kind of begs the question: how many more places in Wine should the > volatile keyword be used? I find it hard to believe that this is the only > spot in a large very low-level project like Wine. You're comment is absolutely right. The thing is, those bugs are especially hard to find out and require very careful code examination. IMHO, performing code review of the whole tree for missing volatile keywords would be a waste of time compared to do it on a case by case basis. Simply keep in mind that those bugs may happen - especially with "aggressive" compilers such as gcc 2.96. If a bug didn't happen with the previous compiler and does show up with the latest release, it might be a good candidate. Now try to don't go paranoid about compiler issues when WINE crashes with your new Linux installations ;) Francois

March 29, 2001

Re: controls/edit.c

by Ulrich Czekalla

I forgot to plug a region leak before I sent the patch in. I have attached an updated patch. /Ulrich Ulrich Czekalla wrote: > > This patch modifies the edit control to keep the line format data > and simply update it as changes occur. It also uses the line data > to calculate a proper update region. The result is a significant > reduction in flicker. Since this is a big change to the format > engine of the edit control it should be tested for a while before > committing. > > Changelog: > Ulrich Czekalla <uczekalla(a)codeweavers.com> > Update format engine to reduce flicker > Index: controls/edit.c =================================================================== RCS file: /home/wine/wine/controls/edit.c,v retrieving revision 1.75 diff -u -w -r1.75 edit.c --- controls/edit.c 2001/03/13 23:31:08 1.75 +++ controls/edit.c 2001/03/29 17:31:36 @@ -63,6 +63,7 @@ INT net_length; /* netto length of a line in visible characters */ LINE_END ending; INT width; /* width of the line in pixels */ + INT index; /* line index into the buffer */ struct tagLINEDEF *next; } LINEDEF; @@ -172,7 +173,7 @@ /* * Helper functions only valid for one type of control */ -static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es); +static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es, INT iStart, INT iEnd, INT delta, HRGN hrgn); static void EDIT_CalcLineWidth_SL(WND *wnd, EDITSTATE *es); static LPWSTR EDIT_GetPasswordPointer_SL(EDITSTATE *es); static void EDIT_MoveDown_ML(WND *wnd, EDITSTATE *es, BOOL extend); @@ -263,6 +264,7 @@ static void EDIT_WM_Timer(WND *wnd, EDITSTATE *es); static LRESULT EDIT_WM_VScroll(WND *wnd, EDITSTATE *es, INT action, INT pos); static void EDIT_UpdateText(WND *wnd, LPRECT rc, BOOL bErase); +static void EDIT_UpdateTextRegion(WND *wnd, HRGN hrgn, BOOL bErase); LRESULT WINAPI EditWndProcA(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); LRESULT WINAPI EditWndProcW(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); @@ -1132,100 +1134,250 @@ * a soft return '\r\r\n' or a hard return '\r\n' * */ -static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es) +static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es, INT istart, INT iend, INT delta, HRGN hrgn) { HDC dc; HFONT old_font = 0; - LPWSTR start, cp; + LPWSTR current_position, cp; INT fw; - LINEDEF *current_def; - LINEDEF **previous_next; + LINEDEF *current_line; + LINEDEF *previous_line; + LINEDEF *start_line; + INT line_index = 0, nstart_line = 0, nstart_index = 0; + INT line_count = es->line_count; + INT orig_net_length; + RECT rc; - current_def = es->first_line_def; - do { - LINEDEF *next_def = current_def->next; - HeapFree(GetProcessHeap(), 0, current_def); - current_def = next_def; - } while (current_def); - es->line_count = 0; - es->text_width = 0; + if (istart == iend && delta == 0) + return; dc = GetDC(wnd->hwndSelf); if (es->font) old_font = SelectObject(dc, es->font); + previous_line = NULL; + current_line = es->first_line_def; + + /* Find starting line. istart must lie inside an existing line or + * at the end of buffer */ + do { + if (istart < current_line->index + current_line->length || + current_line->ending == END_0) + break; + + previous_line = current_line; + current_line = current_line->next; + line_index++; + } while (current_line); + + if (!current_line) /* Error occurred start is not inside previous buffer */ + { + FIXME(" modification occurred outside buffer\n"); + return; + } + + /* Remember start of modifications in order to calculate update region */ + nstart_line = line_index; + nstart_index = current_line->index; + + /* We must start to reformat from the previous line since the modifications + * may have caused the line to wrap upwards. */ + if (!(es->style & ES_AUTOHSCROLL) && line_index > 0) + { + line_index--; + current_line = previous_line; + } + start_line = current_line; + fw = es->format_rect.right - es->format_rect.left; - start = es->text; - previous_next = &es->first_line_def; + current_position = es->text + current_line->index; do { - current_def = HeapAlloc(GetProcessHeap(), 0, sizeof(LINEDEF)); - current_def->next = NULL; - cp = start; + if (current_line != start_line) + { + if (!current_line || current_line->index + delta > current_position - es->text) + { + /* The buffer has been expanded, create a new line and + insert it into the link list */ + LINEDEF *new_line = HeapAlloc(GetProcessHeap(), 0, sizeof(LINEDEF)); + new_line->next = previous_line->next; + previous_line->next = new_line; + current_line = new_line; + es->line_count++; + } + else if (current_line->index + delta < current_position - es->text) + { + /* The previous line merged with this line so we delete this extra entry */ + previous_line->next = current_line->next; + HeapFree(GetProcessHeap(), 0, current_line); + current_line = previous_line->next; + es->line_count--; + continue; + } + else /* current_line->index + delta == current_position */ + { + if (current_position - es->text > iend) + break; /* We reached end of line modifications */ + /* else recalulate this line */ + } + } + + current_line->index = current_position - es->text; + orig_net_length = current_line->net_length; + + /* Find end of line */ + cp = current_position; while (*cp) { if ((*cp == '\r') && (*(cp + 1) == '\n')) break; cp++; } + + /* Mark type of line termination */ if (!(*cp)) { - current_def->ending = END_0; - current_def->net_length = strlenW(start); - } else if ((cp > start) && (*(cp - 1) == '\r')) { - current_def->ending = END_SOFT; - current_def->net_length = cp - start - 1; + current_line->ending = END_0; + current_line->net_length = strlenW(current_position); + } else if ((cp > current_position) && (*(cp - 1) == '\r')) { + current_line->ending = END_SOFT; + current_line->net_length = cp - current_position - 1; } else { - current_def->ending = END_HARD; - current_def->net_length = cp - start; + current_line->ending = END_HARD; + current_line->net_length = cp - current_position; } - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, - start, current_def->net_length, + + /* Calculate line width */ + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, + current_position, current_line->net_length, es->tabs_count, es->tabs)); + /* FIXME: check here for lines that are too wide even in AUTOHSCROLL (> 32767 ???) */ - if ((!(es->style & ES_AUTOHSCROLL)) && (current_def->width > fw)) { + if ((!(es->style & ES_AUTOHSCROLL)) && (current_line->width > fw)) { INT next = 0; INT prev; do { prev = next; - next = EDIT_CallWordBreakProc(es, start - es->text, - prev + 1, current_def->net_length, WB_RIGHT); - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, - start, next, es->tabs_count, es->tabs)); - } while (current_def->width <= fw); - if (!prev) { + next = EDIT_CallWordBreakProc(es, current_position - es->text, + prev + 1, current_line->net_length, WB_RIGHT); + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, + current_position, next, es->tabs_count, es->tabs)); + } while (current_line->width <= fw); + if (!prev) { /* Didn't find a line break so force a break */ next = 0; do { prev = next; next++; - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, - start, next, es->tabs_count, es->tabs)); - } while (current_def->width <= fw); + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, + current_position, next, es->tabs_count, es->tabs)); + } while (current_line->width <= fw); if (!prev) prev = 1; } - current_def->net_length = prev; - current_def->ending = END_WRAP; - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, start, - current_def->net_length, es->tabs_count, es->tabs)); + + /* If the first line we are calculating, wrapped before istart, we must + * adjust istart in order for this to be reflected in the update region. */ + if (current_line->index == nstart_index && istart > current_line->index + prev) + istart = current_line->index + prev; + /* else if we are updating the previous line before the first line we + * are re-caulculating and it expanded */ + else if (current_line == start_line && + current_line->index != nstart_index && orig_net_length < prev) + { + /* Line expanded due to an upwards line wrap so we must partially include + * previous line in update region */ + nstart_line = line_index; + nstart_index = current_line->index; + istart = current_line->index + orig_net_length; + } + + current_line->net_length = prev; + current_line->ending = END_WRAP; + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, current_position, + current_line->net_length, es->tabs_count, es->tabs)); } - switch (current_def->ending) { + + + /* Adjust length to include line termination */ + switch (current_line->ending) { case END_SOFT: - current_def->length = current_def->net_length + 3; + current_line->length = current_line->net_length + 3; break; case END_HARD: - current_def->length = current_def->net_length + 2; + current_line->length = current_line->net_length + 2; break; case END_WRAP: case END_0: - current_def->length = current_def->net_length; + current_line->length = current_line->net_length; break; } - es->text_width = max(es->text_width, current_def->width); - start += current_def->length; - *previous_next = current_def; - previous_next = &current_def->next; - es->line_count++; - } while (current_def->ending != END_0); + es->text_width = max(es->text_width, current_line->width); + current_position += current_line->length; + previous_line = current_line; + current_line = current_line->next; + line_index++; + } while (previous_line->ending != END_0); + + /* Finish adjusting line index's by delta or remove hanging lines */ + if (previous_line->ending == END_0) + { + LINEDEF *pnext = NULL; + + previous_line->next = NULL; + while (current_line) + { + pnext = current_line->next; + HeapFree(GetProcessHeap(), 0, current_line); + current_line = pnext; + es->line_count--; + } + } + else + { + while (current_line) + { + current_line->index += delta; + current_line = current_line->next; + } + } + + /* Calculate rest of modification rectangle */ + if (hrgn) + { + HRGN tmphrgn; + /* + * We calculate two rectangles. One for the first line which may have + * an indent with respect to the format rect. The other is a format-width + * rectangle that spans the rest of the lines that changed or moved. + */ + rc.top = es->format_rect.top + nstart_line * es->line_height - + (es->y_offset * es->line_height); /* Adjust for vertical scrollbar */ + rc.bottom = rc.top + es->line_height; + rc.left = es->format_rect.left + (INT)LOWORD(GetTabbedTextExtentW(dc, + es->text + nstart_index, istart - nstart_index, + es->tabs_count, es->tabs)) - es->x_offset; /* Adjust for horz scroll */ + rc.right = es->format_rect.right; + SetRectRgn(hrgn, rc.left, rc.top, rc.right, rc.bottom); + + rc.top = rc.bottom; + rc.left = es->format_rect.left; + rc.right = es->format_rect.right; + /* + * If lines were added or removed we must re-paint the remainder of the + * lines since the remaining lines were either shifted up or down. + */ + if (line_count < es->line_count) /* We added lines */ + rc.bottom = es->line_count * es->line_height; + else if (line_count > es->line_count) /* We removed lines */ + rc.bottom = line_count * es->line_height; + else + rc.bottom = line_index * es->line_height; + rc.bottom -= (es->y_offset * es->line_height); /* Adjust for vertical scrollbar */ + tmphrgn = CreateRectRgn(rc.left, rc.top, rc.right, rc.bottom); + CombineRgn(hrgn, hrgn, tmphrgn, RGN_OR); + DeleteObject(tmphrgn); + } + if (es->font) SelectObject(dc, old_font); + ReleaseDC(wnd->hwndSelf, dc); } @@ -2140,7 +2292,7 @@ es->format_rect.bottom = es->format_rect.top + es->line_height; if ((es->style & ES_MULTILINE) && !(es->style & ES_AUTOHSCROLL)) - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); } @@ -2836,6 +2988,7 @@ UINT e; UINT i; LPWSTR p; + HRGN hrgn = 0; TRACE("%s, can_undo %d, send_update %d\n", debugstr_w(lpsz_replace), can_undo, send_update); @@ -2916,9 +3069,14 @@ CharLowerBuffW(p, strl); s += strl; } - /* FIXME: really inefficient */ if (es->style & ES_MULTILINE) - EDIT_BuildLineDefs_ML(wnd, es); + { + INT s = min(es->selection_start, es->selection_end); + + hrgn = CreateRectRgn(0, 0, 0, 0); + EDIT_BuildLineDefs_ML(wnd, es, s, s + strl, + strl - (es->selection_end - es->selection_start), hrgn); + } else EDIT_CalcLineWidth_SL(wnd, es); @@ -2930,7 +3088,12 @@ /* force scroll info update */ EDIT_UpdateScrollInfo(wnd, es); - /* FIXME: really inefficient */ + if (hrgn) + { + EDIT_UpdateTextRegion(wnd, hrgn, TRUE); + DeleteObject(hrgn); + } + else EDIT_UpdateText(wnd, NULL, TRUE); if(es->flags & EF_UPDATE) @@ -3134,7 +3297,7 @@ EDIT_EM_EmptyUndoBuffer(es); es->flags &= ~EF_MODIFIED; es->flags &= ~EF_UPDATE; - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); EDIT_EM_ScrollCaret(wnd, es); /* force scroll info update */ @@ -3200,7 +3363,7 @@ EDIT_EM_EmptyUndoBuffer(es); es->flags &= ~EF_MODIFIED; es->flags &= ~EF_UPDATE; - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); EDIT_EM_ScrollCaret(wnd, es); /* force scroll info update */ @@ -3403,7 +3566,7 @@ es->word_break_proc16 = NULL; if ((es->style & ES_MULTILINE) && !(es->style & ES_AUTOHSCROLL)) { - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); } } @@ -3422,7 +3585,7 @@ es->word_break_proc = NULL; es->word_break_proc16 = wbp; if ((es->style & ES_MULTILINE) && !(es->style & ES_AUTOHSCROLL)) { - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); } } @@ -3683,6 +3846,8 @@ */ static void EDIT_WM_Destroy(WND *wnd, EDITSTATE *es) { + LINEDEF *pc, *pp; + if (es->hloc32W) { while (LocalUnlock(es->hloc32W)) ; LocalFree(es->hloc32W); @@ -3695,6 +3860,15 @@ while (LOCAL_Unlock(wnd->hInstance, es->hloc16)) ; LOCAL_Free(wnd->hInstance, es->hloc16); } + + pc = es->first_line_def; + while (pc) + { + pp = pc->next; + HeapFree(GetProcessHeap(), 0, pc); + pc = pp; + } + HeapFree(GetProcessHeap(), 0, es); *(EDITSTATE **)wnd->wExtra = NULL; } @@ -4447,7 +4621,7 @@ EDIT_SetRectNP(wnd, es, &r); if (es->style & ES_MULTILINE) - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); else EDIT_CalcLineWidth_SL(wnd, es); @@ -4678,6 +4852,21 @@ if (dy) EDIT_EM_LineScroll(wnd, es, 0, dy); return 0; +} + +/********************************************************************* + * + * EDIT_UpdateText + * + */ +static void EDIT_UpdateTextRegion(WND *wnd, HRGN hrgn, BOOL bErase) +{ + EDITSTATE *es = *(EDITSTATE **)((wnd)->wExtra); + + if (es->flags & EF_UPDATE) + EDIT_NOTIFY_PARENT(es, EN_UPDATE, "EN_UPDATE"); + + InvalidateRgn(wnd->hwndSelf, hrgn, bErase); }

March 29, 2001

Re: OpenGL Visual Management ... continued.

by lawson_whitney＠juno.com

On Thu, 29 Mar 2001, Gavriel State wrote: > Can you tell me: > - What video card you're using > - What bit depth and resolution you've got > - Whether the behaviour continues if you turn off the setup_opengl_visual() > call in dlls/x11drv/x11drv_main.c No. To be precise, I did exactly: diff -ur /gp/gav/was/dlls/x11drv/x11drv_main.c dlls/x11drv/x11drv_main.c --- /gp/gav/was/dlls/x11drv/x11drv_main.c Wed Mar 28 22:31:00 2001 +++ dlls/x11drv/x11drv_main.c Thu Mar 29 10:23:03 2001 @@ -379,7 +379,8 @@ /* If OpenGL is available, change the default visual, etc as necessary */ #ifdef HAVE_OPENGL - setup_opengl_visual(); +/* setup_opengl_visual(); +*/ #endif /* HAVE_OPENGL */ /* tell the libX11 that we will do input method handling ourselves and everything works fine. > - Whether notepad.exe exhibits the same behaviour (that's the only non > game app I run on a regular basis for testing). How about winemine?? (didn't have notepad.exe handy.) winemine does it, so does programs/notepad. I pulled a 1993 notepad.exe from a tar.bz2 - that would be from wfw3.11, I think. It does it too. > > At a guess - the privately created ColorMaps need to take their initial colors > from the Default Color Map? That sounds about right. Oh, at one point I reverted only wnd.c - no difference - then palette.c. Colors seemed better with the pointer off the window IIRC, but it still went to black and white withe the pointer on the desktop. > > I'll try to have a further look into it tomorrow. Sorry for any wasted time. > > -Gav > > -- > Gavriel State, CEO > TransGaming Technologies Inc. > http://www.transgaming.com > gav(a)transgaming.com > Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 29, 2001

Re: OpenGL Visual Management

by lawson_whitney＠juno.com

On Thu, 29 Mar 2001, Gavriel State wrote: > Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I > don't remember getting it when testing the 3dfx card I just loaned out to > someone. Maybe I flubbed the 8-bit testing there... > > Can you tell me: > - What video card you're using (**) Mach64: Graphics device ID: "ATI Mach64 CT (264CT)" > - What bit depth and resolution you've got (--) Mach64: PCI: Mach64 CT rev 9, Aperture @ 0xfe000000, Block I/O @ 0xfc00 (--) Mach64: Card type: PCI (--) Mach64: Memory type: DRAM (1) (--) Mach64: Clock type: Internal (--) Mach64: Maximum allowed dot-clock: 135.000 MHz (**) Mach64: Mode "640x480": mode clock = 45.800 (**) Mach64: Mode "800x600": mode clock = 69.650 (**) Mach64: Mode "1024x768": mode clock = 85.000 (**) Mach64: Mode "1280x1024": mode clock = 110.000 (--) Mach64: Virtual resolution: 1280x1024 (--) Mach64: Video RAM: 2048k (--) Mach64: Using hardware cursor (--) Mach64: Using 16 MB aperture @ 0xfe000000 (--) Mach64: Ramdac is Internal (--) Mach64: Ramdac speed: 135 MHz (--) Mach64: Using 8 bits per RGB value What is bit depth? :-) can you tell from that? That is interesting. At 16 bpp, the symptoms I reported don't occur, and all is well. I guess you suspected that, but it didn't occur to me to check before. I might be the only wine user who habitually uses 8bpp: I can't see any difference between 8 and 16 bpp. Well, with your patch in I can. > - Whether the behaviour continues if you turn off the setup_opengl_visual() > call in dlls/x11drv/x11drv_main.c > - Whether notepad.exe exhibits the same behaviour (that's the only non > game app I run on a regular basis for testing). > > > No doubt I am not well set up for DGA: > > DGA shouldn't matter for this stuff at all. > > > I haven't really looked into it much yet...maybe you will see right off > > what you or I have done wrong? > > At a guess - the privately created ColorMaps need to take their initial colors > from the Default Color Map? > > I'll try to have a further look into it tomorrow. Sorry for any wasted time. > > -Gav > > -- > Gavriel State, CEO > TransGaming Technologies Inc. > http://www.transgaming.com > gav(a)transgaming.com > I'll get on with some more tests now, but I want to give you that to start with. Lawson ---cut here Dammit, my winelib sendmail program won't work unless X is running. Try again. ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 29, 2001

Re: OpenGL Visual Management

by Gavriel State

lawson_whitney(a)juno.com wrote: > > On Mon, 26 Mar 2001, Gavriel State wrote: > > > This patch fixes several issues with the way OpenGL manages visuals: > > Something is not right, I think. Ordinary apps (Dmitry's About.exe, > say) look as if they were using a vga16 server - unless the pointer is > over the desktop: then the entire X display is black and white. > Without a desktop with managed moving the pointer over the app's window > radically changes the palette for the whole screen, but not to black and > white. With neither managed nor desktop, the pointer has no effect on > the palette. Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I don't remember getting it when testing the 3dfx card I just loaned out to someone. Maybe I flubbed the 8-bit testing there... Can you tell me: - What video card you're using - What bit depth and resolution you've got - Whether the behaviour continues if you turn off the setup_opengl_visual() call in dlls/x11drv/x11drv_main.c - Whether notepad.exe exhibits the same behaviour (that's the only non game app I run on a regular basis for testing). > No doubt I am not well set up for DGA: DGA shouldn't matter for this stuff at all. > I haven't really looked into it much yet...maybe you will see right off > what you or I have done wrong? At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map? I'll try to have a further look into it tomorrow. Sorry for any wasted time. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 29, 2001