Bug 91955 - Rename ENABLE_FILTERS to ENABLE_SVG_FILTERS
Summary: Rename ENABLE_FILTERS to ENABLE_SVG_FILTERS
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P5 Trivial
Assignee: Kent Tamura
URL:
Keywords:
Depends on:
Blocks: 90846
  Show dependency treegraph
 
Reported: 2012-07-22 20:41 PDT by Kent Tamura
Modified: 2012-08-08 18:42 PDT (History)
10 users (show)

See Also:


Attachments
Patch (160.49 KB, patch)
2012-07-22 20:47 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kent Tamura 2012-07-22 20:41:54 PDT
All other SVG-related flags are prefixed with SVG_.
Comment 1 Kent Tamura 2012-07-22 20:47:42 PDT
Created attachment 153728 [details]
Patch
Comment 2 Dirk Schulze 2012-07-22 21:59:54 PDT
Comment on attachment 153728 [details]
Patch

I am curious, beside the name difference, is there any reason for doing this?
Comment 3 Kent Tamura 2012-07-22 22:17:29 PDT
(In reply to comment #2)
> (From update of attachment 153728 [details])
> I am curious, beside the name difference, is there any reason for doing this?

This is just for consistency (the name FILTERS makes me uncomfortable because it doesn't start with SVG_), and has no concrete benefit. If anyone objects this change, I won't proceed this.
Comment 4 Dirk Schulze 2012-07-22 22:22:35 PDT
The filter code was planned to be independent of SVG. This would make it possible to reuse filters for CSS filters and that is why the filter code is in platform, even if it was not platform dependent at that time. Since CSS filters were done with HW acceleration from the beginning, I am not sure if this idea is still reasonable. Some implementations might choose the software rendering as fallback. In this case SVG_FILTERS might be confusing as well.
Comment 5 Kent Tamura 2012-07-22 22:47:52 PDT
(In reply to comment #4)
> The filter code was planned to be independent of SVG. This would make it possible to reuse filters for CSS filters and that is why the filter code is in platform, even if it was not platform dependent at that time. Since CSS filters were done with HW acceleration from the beginning, I am not sure if this idea is still reasonable. Some implementations might choose the software rendering as fallback. In this case SVG_FILTERS might be confusing as well.

Hmm, so the intention of FILTER is NOT
 * Enabling the SVG filter feature, and required software image filter code.
but
 * Using software image filter code, and the SVG filter feature is exposed only if FILTER is enabled


I wonder if we should separate FILTER to two flags, ENABLE_SVG_FILTERS and ENABLE_SOFTWARE_FILTERS/WTF_USE_SOFTWARE_FILTERS.
Comment 6 Eric Seidel (no email) 2012-08-07 16:35:49 PDT
This is a blast from the past.  I believe it used to be called SVG_FILTERS and was renamed before.
Comment 7 Dirk Schulze 2012-08-08 09:37:39 PDT
(In reply to comment #6)
> This is a blast from the past.  I believe it used to be called SVG_FILTERS and was renamed before.

Again, it doesn't make sense to differ between SVG_FILTERS and FILTERS, since the code depends on each other. CSS Filters need SVG Filters now and in the near future the other way around. Closing this bug as invalid.
Comment 8 Kent Tamura 2012-08-08 18:10:40 PDT
(In reply to comment #7)
> Again, it doesn't make sense to differ between SVG_FILTERS and FILTERS, since the code depends on each other. CSS Filters need SVG Filters now and in the near future the other way around. Closing this bug as invalid.

What do you think about renaming FILTERS to SOFTWARE_IMAGE_FILTERS?
My concern is that "FILTERS" is too short and hard to understand what it is.
Comment 9 Dirk Schulze 2012-08-08 18:42:52 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > Again, it doesn't make sense to differ between SVG_FILTERS and FILTERS, since the code depends on each other. CSS Filters need SVG Filters now and in the near future the other way around. Closing this bug as invalid.
> 
> What do you think about renaming FILTERS to SOFTWARE_IMAGE_FILTERS?
> My concern is that "FILTERS" is too short and hard to understand what it is.

It is not only software and is designed to use HW acceleration. My initial focus was just to provide software rendering as fallback. I don't really understand why you want rename it when there is no need to do so. If you don't want SVG, the SVG part of filters get deactivated anyway. So no problem. Why do you want to build CSS Filters with SVG but without SVG Filters? I don't think that this will help for the general project and just adds more confusion instead of less.