скалогрыз писал(а):zg, твой шаг чтобы закрыть баг репорт?!
пока закрывать рано.Статистика: Добавлено z.g — 10.05.2010 13:07:46
]]>
z.g писал(а):аналогично. это ж системный вызов. но в vcl setpixel используется не так заметно 
сходу только в TBitBtn при каких-то экстремальных свойствах.
сходу только в TBitBtn при каких-то экстремальных свойствах.может быть в новых версиях делфи предусмотрено такое же исправление...
Статистика: Добавлено скалогрыз — 09.05.2010 23:30:20
]]>
скалогрыз писал(а):Думаю нет причин для взаимных обвинений.
да я никого не обвиняю, патч в итоге приняли, я рад (вот так бы с майкрософтом всё просто было).для меня это главный опыт данной истории.Чем больше критических причин "для принятия" патча будет изложено, тем скорее он будет принят ^^
в ближайшие дни проверю и если всё ок — закрою.zg, твой шаг чтобы закрыть баг репорт?!
аналогично. это ж системный вызов. но в vcl setpixel используется не так заметнокто-нибудь проверял как себя SetPixel ведёт в Делфи под Вистой?!
сходу только в TBitBtn при каких-то экстремальных свойствах.Статистика: Добавлено z.g — 09.05.2010 22:17:48
]]>
z.g писал(а):1. ...
Думаю нет причин для взаимных обвинений.
Чем больше критических причин "для принятия" патча будет изложено, тем скорее он будет принят ^^
например, "если не принять патч, то реки выйдут из берегов, и день превратиться в ночь, и падёт на нас огненный дождь" звучит убедительно! но "иначе LCL компоненты будут глючить на Висте" звучит ещё убедительнее )) да ещё и со скриншотами... Не у всех же Виста стоит!
я ошибаюсь или патч принят? http://bugs.freepascal.org/view.php?id=15822
zg, твой шаг чтобы закрыть баг репорт?!
кто-нибудь проверял как себя SetPixel ведёт в Делфи под Вистой?!
Статистика: Добавлено скалогрыз — 09.05.2010 21:40:56
]]>
Павел Ишенин писал(а):При описании бага не было упомянута зависимость LCL компонент от него.
1. можно было уточнить.2. для меня лично очевидно, что для своих вызовов патчить lcl не обязательно.
3. зависит не только lcl, но ещё как минимум дизайнер.
4. опять же поиск по исходникам lcl не такой уж сложный.
Статистика: Добавлено z.g — 09.05.2010 21:20:28
]]>
]]>
.wOvAN писал(а):Проверка на аэро, но вызывать придется на каждый SetPixel (((гемор
кланяемся в ножки за это M$ программистам
если есть оповещение о том, что изменилась тема (аеро или нет), то можно повеситься на него, и менять вызываемую процедуру.
Однако проще забить и рисовать все пиксели на Висте с 9м не нулевым битом через прямоугольник.
Статистика: Добавлено скалогрыз — 08.05.2010 22:36:16
]]>
Код:
uses DwmApi;
function IsCompositionEnabled: Boolean;
var Enabled:Bool;
begin
if DWMDLL_Loaded then DwmIsCompositionEnabled(Enabled);
Result := Enabled;
end;
initialization
if IsVista then
DWMDLL_Loaded := InitDwmLibrary;
else
DWMDLL_Loaded:=False;
finalization
if DWMDLL_Loaded then FreeDwmLibrary;
DWMDLL_Loaded:=False;
end.
Статистика: Добавлено .wOvAN — 08.05.2010 22:09:56
]]>
самое отвратительное, что с Aero работает... по-правильному - необходимо проверять включено Aero или нет.
Статистика: Добавлено скалогрыз — 08.05.2010 21:22:15
]]>
скалогрыз писал(а):я ещё раз повторю, если проблема в Висте... то зачем изменять код для ВСЕХ вин версий?
незачем, я с вашим кодом согласился в первом ответе.Статистика: Добавлено z.g — 08.05.2010 20:59:00
]]>
Vista-64 (классическая тема)
Статистика: Добавлено скалогрыз — 08.05.2010 20:51:45
]]>
скалогрыз писал(а):???? проблемы такой нет в WinXP или ранее версиях.
да. сломали в висте, в win7 поломанный код вообще выкинут. в багрепорте есть ссылка на ms группу, ещё в 2007 году обсуждалось.Статистика: Добавлено z.g — 08.05.2010 20:48:27
]]>
это только в win32. во всех интервейсах — поболее.
???? проблемы такой нет в WinXP или ранее версиях.
пробую на Vista-64:
Код:
procedure TForm1.FormPaint(Sender: TObject);
var
i, j : Integer;
begin
for i:=0 to 999 do
for j:=0 to 999 do
Canvas.Pixels[i,j]:=clBlue;
end;
Статистика: Добавлено скалогрыз — 08.05.2010 20:45:56
]]>
скалогрыз писал(а):а проблема-то только в висте...?!
виста и сервер 2008-ой (сервера бывают терминальные, и на них тоже запускаются приложения). это только в win32. во всех интервейсах — поболее.workaround используется два раза
Статистика: Добавлено z.g — 08.05.2010 20:43:28
]]>
z.g писал(а):наоборот, под w2k8/вистой проблема решается.
а проблема-то только в висте...?!
workaround используется два раза
Статистика: Добавлено скалогрыз — 08.05.2010 20:26:20
]]>
скалогрыз писал(а):ну... всё правильно, смысл LCL в кросс-платформенной разработке.
как предложенный патч ломает кросплатформенность? наоборот, под w2k8/вистой проблема решается.вообще поиск слова "workaround" в папке \lcl\interfaces сильно противоречит указанной фразе.
Статистика: Добавлено z.g — 08.05.2010 20:21:27
]]>
z.g писал(а):я не против пересмотра, но смысл? было ж чётко сказанно:
собственно эта фраза и побудила к созданию топика.
LCL has no goal to workaround system behavior.
собственно эта фраза и побудила к созданию топика.
ну... всё правильно, смысл LCL в кросс-платформенной разработке.
Статистика: Добавлено скалогрыз — 08.05.2010 20:05:56
]]>
скалогрыз писал(а):я бы предложил пересмотреть патч.
я не против пересмотра, но смысл? было ж чётко сказанно:собственно эта фраза и побудила к созданию топика.LCL has no goal to workaound system behavior.
Статистика: Добавлено z.g — 08.05.2010 19:32:02
]]>
Кроме того, добавил бы ещё 1 патч, который рисует выделение в DBGrid-е НЕ используя SetPixel.
Статистика: Добавлено скалогрыз — 08.05.2010 19:23:07
]]>
скалогрыз писал(а):
18%?! ужос!
при собственной тормознутости setpixel 18% там ничего не решают.z.g писал(а):18%. не вижу ничего невероятного.
18%?! ужос!
может быть.так может прислать патч, который выполняет рисование без использования SetPixel?мотивируя тем, что SetPixel устаревшая операция... мало того, DBGrid поддерживает нерусский разработчик!
скорее всего. но это вступает в противоречие с предыдущим предложением.кстати не очень понятно почему используется SetPixel/DrawRubberRect при наличии DrawFocusRect.
чтобы она выглядела одинаково (а не нативно) на всех системах?!
в Additional Information ссылка на связанный баг. там как раз про грид.Odyssey писал(а):z.g писал(а):и как это поможет в отрисовке dbgrid?
Про DBGrid в багтрекере упомянуто не было
в собственном приложении я могу вызвать собственную реализацию.а без этого уточнения действительно может показаться что вы используете SetPixel сами и можете добавить workaround в собственное приложение.
Статистика: Добавлено z.g — 08.05.2010 18:42:15
]]>
z.g писал(а):и как это поможет в отрисовке dbgrid?
Про DBGrid в багтрекере упомянуто не было, а без этого уточнения действительно может показаться что вы используете SetPixel сами и можете добавить workaround в собственное приложение. Если поднять вопрос именно по второму варианту:
z.g писал(а):как исправить отрисовку стандартного dbgrid'а?
там же или в рассылке, возможно получится решить проблему более конструктивно.
P.S. Похожую проблему Vincent закрыл из-за невоспроизводимости.
Статистика: Добавлено Odyssey — 08.05.2010 17:11:40
]]>
z.g писал(а):18%. не вижу ничего невероятного.
18%?! ужос!
и как это поможет в отрисовке dbgrid?
...
вопрос не ко мне, а к разработчикам lcl. там он используется ровно в двух местах: сеточку в дизайне на форме рисовать (можно пережить) и фокусного элемента в dbgrid. а вот это уже плохо. собственно второй вопрос можно переформулировать: как исправить отрисовку стандартного dbgrid'а?
так может прислать патч, который выполняет рисование без использования SetPixel?
мотивируя тем, что SetPixel устаревшая операция... мало того, DBGrid поддерживает нерусский разработчик! 
кстати не очень понятно почему используется SetPixel/DrawRubberRect при наличии DrawFocusRect.
чтобы она выглядела одинаково (а не нативно) на всех системах?!
Статистика: Добавлено скалогрыз — 08.05.2010 16:47:12
]]>
скалогрыз писал(а):а она кстати, будет проседать невероятно. например при выводе 10000 точек, таким вот способом.
18%. не вижу ничего невероятного.да без проблем. однако:Фикс плохой, потому что диктует "фикс для висты" абсолютно для всех Windows систем.
правильнее было бы так:Код:
procedure VistaSetPixel(CanvasHandle: HDC; X, Y: integer; AColor: COLORREF);
var
pen, oldpen: HPEN;
begin
if x and 8=0 then
Windows.SetPixel(CanvasHandle, X, Y, Windows.ColorRef(ColorToRGB(AColor)))
else begin
pen := Windows.CreatePen(PS_SOLID, 1, Windows.ColorRef(ColorToRGB(AColor)));
oldpen := Windows.SelectObject(CanvasHandle, pen);
Windows.MoveToEx(CanvasHandle, X, Y, nil);
Windows.LineTo(CanvasHandle, X, Y + 1);
Windows.SelectObject(CanvasHandle, oldpen);
Windows.DeleteObject(pen);
end;
end;
procedure WinSetPixel(CanvasHandle: HDC; X, Y: integer; AColor: TGraphicsColor);
begin
Windows.SetPixel(CanvasHandle, X, Y, Windows.ColorRef(ColorToRGB(AColor)));
end;
var
IntSetPixel : procedure (anvasHandle: HDC; X, Y: integer; AColor: TGraphicsColor) = @WinSetPixel;
procedure TWin32WidgetSet.DCSetPixel(CanvasHandle: HDC; X, Y: integer; AColor: TGraphicsColor);
begin
IntSetPixel(CanvasHandle, X,Y, AColor);
end;
constructor TWin32WidgetSet.Create;
begin
...
if isWindowsVista then IntSetPixel:=@VistaSetPixel;
...
end;
и никому не будет больно... кроме висты
LCL has no goal to workaound system behavior.
т.е. про производительность ничего сказано не было. нет и всё!
и как это поможет в отрисовке dbgrid?z.g писал(а):2. способы исправления в своём приложении без правки lcl.Код:
procedure MySetPixel(c: TCanvas; x,y: integer; color: TColor);
var
b : TColor;
begin
if not isVista then
c.SetPixel(x,y, color);
else begin
b:=c.Pen.Color; // penwidth+pen+style
c.Pen.Color:=color;
c.FillRect(x, y,x+1, y+1)
c.Pen.Color:=b;
end ;
end;
вопрос не ко мне, а к разработчикам lcl. там он используется ровно в двух местах: сеточку в дизайне на форме рисовать (можно пережить) и фокусного элемента в dbgrid. а вот это уже плохо. собственно второй вопрос можно переформулировать: как исправить отрисовку стандартного dbgrid'а?Но лучший способ - выкинуть SetPixel нафик (зачем он используется?!).
кстити не очень понятно почему используется SetPixel/DrawRubberRect при наличии DrawFocusRect.
Статистика: Добавлено z.g — 08.05.2010 14:14:30
]]>
z.g писал(а):и производительность проседала невероятно
а она кстати, будет проседать невероятно. например при выводе 10000 точек, таким вот способом.
предлагаю даже написать тест и сравнить скорость работы, например в WinXP, отрисовки точек до патчевым и послепатчевым способом!
Опыт работы с DC функциями подсказывает, что скорость упадёт значительно... хотя бы просто за счёт дополнительных call-ов. Не забываем, что на старых компах (где, как-раз висты нет), скорость упадёт ещё сильнее!
z.g писал(а):фикс простой. проблему решает.
Фикс плохой, потому что диктует "фикс для висты" абсолютно для всех Windows систем.
правильнее было бы так:
Код:
procedure VistaSetPixel(CanvasHandle: HDC; X, Y: integer; AColor: COLORREF);
var
pen, oldpen: HPEN;
begin
if x and 8=0 then
Windows.SetPixel(CanvasHandle, X, Y, Windows.ColorRef(ColorToRGB(AColor)))
else begin
pen := Windows.CreatePen(PS_SOLID, 1, Windows.ColorRef(ColorToRGB(AColor)));
oldpen := Windows.SelectObject(CanvasHandle, pen);
Windows.MoveToEx(CanvasHandle, X, Y, nil);
Windows.LineTo(CanvasHandle, X, Y + 1);
Windows.SelectObject(CanvasHandle, oldpen);
Windows.DeleteObject(pen);
end;
end;
procedure WinSetPixel(CanvasHandle: HDC; X, Y: integer; AColor: TGraphicsColor);
begin
Windows.SetPixel(CanvasHandle, X, Y, Windows.ColorRef(ColorToRGB(AColor)));
end;
var
IntSetPixel : procedure (anvasHandle: HDC; X, Y: integer; AColor: TGraphicsColor) = @WinSetPixel;
procedure TWin32WidgetSet.DCSetPixel(CanvasHandle: HDC; X, Y: integer; AColor: TGraphicsColor);
begin
IntSetPixel(CanvasHandle, X,Y, AColor);
end;
constructor TWin32WidgetSet.Create;
begin
...
if isWindowsVista then IntSetPixel:=@VistaSetPixel;
...
end;
и никому не будет больно... кроме висты
z.g писал(а):1. способы исправления в уже готовых приложениях.
если имеется в виду, уже скомпилированных, то ответ - никак! баг Висты
любое приложение использовавшее в Висте SetPixel API, без пересборки не заработает.
z.g писал(а):2. способы исправления в своём приложении без правки lcl.
Код:
procedure MySetPixel(c: TCanvas; x,y: integer; color: TColor);
var
b : TColor;
begin
if not isVista then
c.SetPixel(x,y, color);
else begin
b:=c.Pen.Color; // penwidth+pen+style
c.Pen.Color:=color;
c.FillRect(x, y,x+1, y+1)
c.Pen.Color:=b;
end ;
end;
Но лучший способ - выкинуть SetPixel нафик (зачем он используется?!). Вместо него использовать, например, TBitmap.
Добавлено спустя 4 минуты 51 секунду:
вот ещё можно так написать:
to: Lazarus mailing list <lazarus@lists.lazarus.freepascal.org>
subject: Russian Lazarus developers.
Hello Lazarus team
Why Russian Lazarus developers are so cruel?! Aren't you feeding them?
Could you please reassign the issue (http://bugs.freepascal.org/view.php?id=15822) to some other maintainer not Russian, please. I find my patch to be working, but for some reason, your Russian developer refuses to accept it. I think it's because he's Russian.
Regards,
z.g
Такое письмо порадует немецких разработчиков на 8-9 мая
сорри за троллинг! весна чо!
Статистика: Добавлено скалогрыз — 08.05.2010 12:13:47
]]>
Logo писал(а):Это вы по отношению к Павлу Ишенину?
Вы знаете, а я вот удивляюсь, как у него хватает терпения выслушивать от юзеров всякий бред, обвинения, хамство и при этом еще и эффективно работать.
ну объясните в чём бред, хамство и т.д. ну и на два вопроса ответы раскажите.Вы знаете, а я вот удивляюсь, как у него хватает терпения выслушивать от юзеров всякий бред, обвинения, хамство и при этом еще и эффективно работать.
может быть не злые. но без аргументов и с бесполезными советами. я не знаю как это назвать одним словом по другому.AbakAngelSoft писал(а):Перечитал несколько раз - так и не нашел злых разработчиков.
Статистика: Добавлено z.g — 08.05.2010 11:04:16
]]>
z.g писал(а):собственно по мотивам.
Перечитал несколько раз - так и не нашел злых разработчиков.
Статистика: Добавлено AbakAngelSoft — 08.05.2010 10:51:00
]]>
z.g писал(а):собственно по мотивам.
да я понимаю баг в винде....
да я понимаю баг в винде....
Это вы по отношению к Павлу Ишенину?
Вы знаете, а я вот удивляюсь, как у него хватает терпения выслушивать от юзеров всякий бред, обвинения, хамство и при этом еще и эффективно работать.
Статистика: Добавлено Logo — 08.05.2010 06:42:56
]]>
да я понимаю баг в винде. да формально никто не обязан исправлять. и я понял бы, если бы там был воркэраунд на килобайты кода, или с жуткими сайд эффектами, и производительность проседала невероятно. но реально-то ничего этого нет. фикс простой. проблему решает.
ну и хотелось бы услышать способы исправления:If you want you can fix it in your application.
1. способы исправления в уже готовых приложениях.
2. способы исправления в своём приложении без правки lcl.
Статистика: Добавлено z.g — 08.05.2010 02:11:15
]]>