Значит так.
FM - мне ДИКО нравится. Ещё раз повторю - FM - мне ДИКО нравится.
За СТИЛИЗАЦИЮ и за "слоёный пирог из атомарных контролов".
Но! "Раздаются голоса", что там "не всё оптимально".
Внесу "свои 5 копеек".
Посмотрим на:
TPosition = class(TPersistent)
private
FOnChange: TNotifyEvent;
FY: Single;
FX: Single;
FDefaultValue: TPointF;
FM - мне ДИКО нравится. Ещё раз повторю - FM - мне ДИКО нравится.
За СТИЛИЗАЦИЮ и за "слоёный пирог из атомарных контролов".
Но! "Раздаются голоса", что там "не всё оптимально".
Внесу "свои 5 копеек".
Посмотрим на:
TPosition = class(TPersistent)
private
FOnChange: TNotifyEvent;
FY: Single;
FX: Single;
FDefaultValue: TPointF;
и:
TBounds = class(TPersistent)
private
FRight: Single;
FBottom: Single;
FTop: Single;
FLeft: Single;
FOnChange: TNotifyEvent;
FDefaultValue: TRectF;
-- вообще говоря - FDefaultValue - ЯВЛЯЮТСЯ "лишними".
Они используются "в паре странных мест".
Я у "себя" когда "дотачивал" VGScene - просто закомментировал FDefaultValue и места их использования.
И НИЧЕГО не сломалось.
О чём я? Опять же о HighLoad и "Экономии на спичках".
Но в ДАННОМ случае - это как раз пример "вырастания спичек в брёвна".
За счёт "слоёного пирога".
Ведь "реальные контролы" в конечном итоге становятся "слоёным пирогом" из атомарных.
И тут "экономия на спичках" - начинает играть свою роль.
Ни в КОЕМ СЛУЧАЕ - не хочу "укусить Embarcadero".
Это просто - совет.
Я бы - пересмотрел бы подобные "шероховатости".
Если уж "хочется DefaultValue" - это "легко" решается полиморфизмом.
То же касается и использования интерфейса IControl. По моему скромному мнению - "излишний он". А затраты на получение его - "тоже спички", но тоже "вырастают в брёвна".
Опять же - никого не хочу "укусить". Просто - советую. Я бы сделал бы по-другому.
Ну и "возвращаясь к HighLoad".
Я когда "общался с VGScene" - Она "слегка подтормаживала". Я сделал все её объекты "кешируемыми" (рассказать как?). Говоря языком HighLoad - "пулил всё и вся". И "торможения" - прекратились.
Ну и уж "совсем спички" - использовать nil вместо IdentityMatrix - не эффективнее?
Это моё частное мнение. Вероятно - однобокое.И вероятно - "для частных случаев". Но лишь "частными случаями" - я и занимаюсь.
Никого не хотел обидеть.
Да и ещё. "дочерние атомарные контролы" из которых состоит "слоёный пирог" - ведь используют ТУ ЖЕ САМУЮ матрицу преобразования, что и родительский контрол. ВСЕГДА.
Или я ошибаюсь?
А если не ошибаюсь - тут тоже есть "поле для оптимизации".
А уж "пулить" (выражаясь словами HighLoader'ов) матрицы вот тут:
FLocalMatrix: TMatrix;
FAbsoluteMatrix: TMatrix;
FInvAbsoluteMatrix: TMatrix;
...
FInPaintToAbsMatrix, FInPaintToInvMatrix: TMatrix;
...
ну и там много мест ещё...
Да и ещё. "дочерние атомарные контролы" из которых состоит "слоёный пирог" - ведь используют ТУ ЖЕ САМУЮ матрицу преобразования, что и родительский контрол. ВСЕГДА.
Или я ошибаюсь?
А если не ошибаюсь - тут тоже есть "поле для оптимизации".
А уж "пулить" (выражаясь словами HighLoader'ов) матрицы вот тут:
FLocalMatrix: TMatrix;
FAbsoluteMatrix: TMatrix;
FInvAbsoluteMatrix: TMatrix;
...
FInPaintToAbsMatrix, FInPaintToInvMatrix: TMatrix;
...
ну и там много мест ещё...
-- по-моему - сам бог велел. Хранить, не значения, а указатели. На конкретные экземпляры матриц. Из пула. Их вообще говоря в "обычных" приложениях - немного. Обычно - только IdentityMatrix и есть.
Или я опять ошибаюсь?
Да. И ещё немного расстраивает, что нет возможности "отложить вызов FOnChange" или я опять ошибаюсь?
Да. И ещё немного расстраивает, что нет возможности "отложить вызов FOnChange" или я опять ошибаюсь?
Комментариев нет:
Отправить комментарий