All other SVG-related flags are prefixed with SVG_.
Created attachment 153728 [details] Patch
Comment on attachment 153728 [details] Patch I am curious, beside the name difference, is there any reason for doing this?
(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.
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.
(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.
This is a blast from the past. I believe it used to be called SVG_FILTERS and was renamed before.
(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.
(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.
(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.